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 > <[email protected]>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
