Re: Native OSGi

[Mohammad Nour El-Din <no...@gmail.com>]

Hi Alex...

   Great news

But I have a question ? Why making the native implementation only directed
to C and C++ and not making these specs for *native* implementation as in
terms of native in languages other than Java in which on OSGi compliant can
be implemented not intended to run over the JVM ?

Thoughts ?

On Wed, May 30, 2012 at 9:22 AM, Alexander Broekhuis
<a....@gmail.com>wrote:

> Hi all,
>
> As mentioned on the list, last week we had a meeting to discuss the future
> of Celix and the possibilities for C++ bindings.
>
> This meeting was attended by:
> * Sascha Zelzer (CTK Plugin Framework)
> * Marcel Offermans (Celix Mentor/Champion)
> * Pepijn Noltes (Celix Committer)
> * Myself (Alexander Broekhuis) (Celix Committer)
>
> Even though Sascha was the only "external" person, he received some input
> from two other OSGi like frameworks (nOSGi and SOF).
>
> A summary of this meeting, as well as a rationale for native OSGi
> solutions, can be found on [1]. Most notably is that we see a shared
> interest and a need for a standardized specification (API, Bundle format,
> etc) to be able to share and reuse bundles between those projects.
>
> To this end we have set up a repository on GitHub [2] with the goal to have
> one place for shared resources. For example header files, specifications
> etc. We like to call this the Native OSGi specification.
>
> Since this effort will try to provide a solution for C as well as C++, the
> GitHub repository will also be used to share C/C++ bindings. This makes it
> possible to use/implement bundles in a natural way for both languages.
>
>
> == So what does this mean for Celix?
>
> From this point on we like to see Celix as a reference implementation for
> the specification. So there will probably some changes to the codebase. The
> impact of these changes still have to be researched and discussed.
>
> For a start, the information on the GitHub repository has to grow to
> something which can be used. To reach this we need a medium for some
> discussions, and we want to use the Celix mailing list for this.
>
> While this is a good start, this will still take a lot of work. I am
> looking forward to these discussions, and think this is the right direction
> to go!
>
> Feel free to participate in these discussions and provide input where you
> all see fit!
>
> [1]:
> http://blog.cppmicroservices.org/2012/05/26/native-osgi-meeting-hengelo/
> [2]: https://github.com/abroekhuis/NativeOSGi
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>



-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

Re: Native OSGi

[Mohammad Nour El-Din <no...@gmail.com>]

Ping

On Sat, Jul 7, 2012 at 11:08 PM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:

> Hi Alex...
>
>    Great news
>
> But I have a question ? Why making the native implementation only directed
> to C and C++ and not making these specs for *native* implementation as in
> terms of native in languages other than Java in which on OSGi compliant can
> be implemented not intended to run over the JVM ?
>
> Thoughts ?
>
>
> On Wed, May 30, 2012 at 9:22 AM, Alexander Broekhuis <
> a.broekhuis@gmail.com> wrote:
>
>> Hi all,
>>
>> As mentioned on the list, last week we had a meeting to discuss the future
>> of Celix and the possibilities for C++ bindings.
>>
>> This meeting was attended by:
>> * Sascha Zelzer (CTK Plugin Framework)
>> * Marcel Offermans (Celix Mentor/Champion)
>> * Pepijn Noltes (Celix Committer)
>> * Myself (Alexander Broekhuis) (Celix Committer)
>>
>> Even though Sascha was the only "external" person, he received some input
>> from two other OSGi like frameworks (nOSGi and SOF).
>>
>> A summary of this meeting, as well as a rationale for native OSGi
>> solutions, can be found on [1]. Most notably is that we see a shared
>> interest and a need for a standardized specification (API, Bundle format,
>> etc) to be able to share and reuse bundles between those projects.
>>
>> To this end we have set up a repository on GitHub [2] with the goal to
>> have
>> one place for shared resources. For example header files, specifications
>> etc. We like to call this the Native OSGi specification.
>>
>> Since this effort will try to provide a solution for C as well as C++, the
>> GitHub repository will also be used to share C/C++ bindings. This makes it
>> possible to use/implement bundles in a natural way for both languages.
>>
>>
>> == So what does this mean for Celix?
>>
>> From this point on we like to see Celix as a reference implementation for
>> the specification. So there will probably some changes to the codebase.
>> The
>> impact of these changes still have to be researched and discussed.
>>
>> For a start, the information on the GitHub repository has to grow to
>> something which can be used. To reach this we need a medium for some
>> discussions, and we want to use the Celix mailing list for this.
>>
>> While this is a good start, this will still take a lot of work. I am
>> looking forward to these discussions, and think this is the right
>> direction
>> to go!
>>
>> Feel free to participate in these discussions and provide input where you
>> all see fit!
>>
>> [1]:
>> http://blog.cppmicroservices.org/2012/05/26/native-osgi-meeting-hengelo/
>> [2]: https://github.com/abroekhuis/NativeOSGi
>>
>> --
>> Met vriendelijke groet,
>>
>> Alexander Broekhuis
>>
>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
>


-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

Re: Native OSGi

[Marcel Offermans <ma...@luminis.nl>]

Just as a follow up, there is another way to make different implementations interoperable, and that is via the Remote Services OSGi specification. This allows you do create a "cross container" service registry, and as long as you use an implementation of that specification that has a compatible disovery mechanism and transport protocol you can hook up implementations in all kinds of languages.

That does not mean I think that the effort to align the C/C++ implementations to be compatible is not necessary. On the contrary, C and C++ are very much related and having a model where components written for one container can directly be deployed in another is very worthwhile!

Greetings, Marcel


On Jul 12, 2012, at 11:34 AM, Mohammad Nour El-Din wrote:

> Hi Alex...
> 
> On Thu, Jul 12, 2012 at 9:37 AM, Alexander Broekhuis
> <a....@gmail.com>wrote:
> 
>> Hi,
>> 
>> I have been very bussy, so sorry for the late reply, but thanks for your
>> interest!
>> 
> 
> No problem :)
> 
> 
>> 
>>> 
>>> But I have a question ? Why making the native implementation only
>> directed
>>> to C and C++ and not making these specs for *native* implementation as in
>>> terms of native in languages other than Java in which on OSGi compliant
>> can
>>> be implemented not intended to run over the JVM ?
>>> 
>> 
>> We've discussed this as well, the original Universal-OSGi RFP targeted
>> several other languages as well.
>> But from our point of view we like to keep the focus fairly limited (for
>> the time being).
>> 
>> The mentioned projects all use C/C++ so this is where the most knowledge
>> lies, adding different languages only broadens the scope and makes it more
>> difficult to get some work done. We need more people onboard (with
>> knowledge of that specific language), which makes it more difficult to
>> discuss items etc etc.
>> 
>> Also, we need a specification which explicitly details how several problems
>> are solved in a certain language. Especially the dynamic loading of bundles
>> and bundling itself needs attention. For other languages this is solved
>> differently as for C/C++ (even though C and C++ are different languages,
>> the dynamic aspects are solved in the same manner).
>> 
>> So I personally think it makes more sense to create a separate
>> specification for other languages (language groups) detailing the specific
>> aspects of that language. Some overall document detailing the generic
>> aspects of OSGi would make sense in such case.
>> 
>> But for now, this is not our goal, I think we will have enough of a
>> challenge with the current path we selected/set out.
>> 
> 
> I see your point, thanks for the thorough explanation :)
> 
> 
>> 
>> 
>> --
>> Met vriendelijke groet,
>> 
>> Alexander Broekhuis
>> 
> 
> 
> 
> -- 
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein

Re: Native OSGi

[Mohammad Nour El-Din <no...@gmail.com>]

Hi Alex...

On Thu, Jul 12, 2012 at 9:37 AM, Alexander Broekhuis
<a....@gmail.com>wrote:

> Hi,
>
> I have been very bussy, so sorry for the late reply, but thanks for your
> interest!
>

No problem :)


>
> >
> > But I have a question ? Why making the native implementation only
> directed
> > to C and C++ and not making these specs for *native* implementation as in
> > terms of native in languages other than Java in which on OSGi compliant
> can
> > be implemented not intended to run over the JVM ?
> >
>
> We've discussed this as well, the original Universal-OSGi RFP targeted
> several other languages as well.
> But from our point of view we like to keep the focus fairly limited (for
> the time being).
>
> The mentioned projects all use C/C++ so this is where the most knowledge
> lies, adding different languages only broadens the scope and makes it more
> difficult to get some work done. We need more people onboard (with
> knowledge of that specific language), which makes it more difficult to
> discuss items etc etc.
>
> Also, we need a specification which explicitly details how several problems
> are solved in a certain language. Especially the dynamic loading of bundles
> and bundling itself needs attention. For other languages this is solved
> differently as for C/C++ (even though C and C++ are different languages,
> the dynamic aspects are solved in the same manner).
>
> So I personally think it makes more sense to create a separate
> specification for other languages (language groups) detailing the specific
> aspects of that language. Some overall document detailing the generic
> aspects of OSGi would make sense in such case.
>
> But for now, this is not our goal, I think we will have enough of a
> challenge with the current path we selected/set out.
>

I see your point, thanks for the thorough explanation :)


>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>



-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

Re: Native OSGi

[Alexander Broekhuis <a....@gmail.com>]

Hi,

I have been very bussy, so sorry for the late reply, but thanks for your
interest!

>
> But I have a question ? Why making the native implementation only directed
> to C and C++ and not making these specs for *native* implementation as in
> terms of native in languages other than Java in which on OSGi compliant can
> be implemented not intended to run over the JVM ?
>

We've discussed this as well, the original Universal-OSGi RFP targeted
several other languages as well.
But from our point of view we like to keep the focus fairly limited (for
the time being).

The mentioned projects all use C/C++ so this is where the most knowledge
lies, adding different languages only broadens the scope and makes it more
difficult to get some work done. We need more people onboard (with
knowledge of that specific language), which makes it more difficult to
discuss items etc etc.

Also, we need a specification which explicitly details how several problems
are solved in a certain language. Especially the dynamic loading of bundles
and bundling itself needs attention. For other languages this is solved
differently as for C/C++ (even though C and C++ are different languages,
the dynamic aspects are solved in the same manner).

So I personally think it makes more sense to create a separate
specification for other languages (language groups) detailing the specific
aspects of that language. Some overall document detailing the generic
aspects of OSGi would make sense in such case.

But for now, this is not our goal, I think we will have enough of a
challenge with the current path we selected/set out.


-- 
Met vriendelijke groet,

Alexander Broekhuis