incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Native OSGi
Date Thu, 12 Jul 2012 09:54:30 GMT
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
> <>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

View raw message