incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <>
Subject Re: Poddling status
Date Wed, 18 Jan 2012 08:53:20 GMT
On Tue, Jan 17, 2012 at 9:56 PM, Sascha Zelzer
<> wrote:
> On 01/13/2012 07:23 PM, Marcel Offermans wrote:
>> On Jan 12, 2012, at 11:15 AM, Alexander Broekhuis wrote:
>>> - Use Celix as an alternative for JNI, which provides a more robust
>>> solution. The processes are separated, and one side crashing won't take
>>> down the other.
>>> Does anyone have a specific use case or interest in this that can be used
>>> as a showcase?
> I don't, sorry. We do not use Java at all. However, I am still interested in
> compatibility with Java OSGi services (probably using "remote services" in
> some way).
>>> - During many discussions C++ is mentioned, also seing the replies now
>>> again there seems to be quite a lot of interest in an OSGi implementation
>>> in C++.
>>> - There are several C++ OSGi like implementations, collaboration with
>>> these
>>> projects could benefit both.
>> It makes a lot of sense to reach out to those communities to see if we can
>> collaborate.
> Sounds very good to me. At the very least, the developers/communities get to
> know each other and see if they share the same visions.
>>> Seeing this interest in C++, I think it would be a good starting point to
>>> try and reach a broader community.
>>> The following C++ frameworks are mentioned:
>>> - nOSGi:
>>> - SOF:
>>> - CommonTK Plugin Framework:
>> If anybody else has additions to this list, let us know!
>> Maybe closer to home, other Apache projects that are interested in
>> collaborating. For example, we are currently using the APR and might even do
>> ports to platforms that currently are not supported yet. Another example
>> could be to look at other OSGi projects (Felix, ACE, Karaf, ...) and see if
>> there are things that could be of interest to them (I'm thinking they might
>> be interested in a JNI alternative, for example).
>>> Areas where I think collaboration might be interesting are:
>>> * Bundling
>>> * Metadata
>>> * API (how to map the OSGi specification to C/C++)
>> I'm sure there are many technical issues to work on, once we get in
>> contact. The first thing we should do is to see if we have common goals.
>> Since we're all implementing the OSGi specification at least at a high level
>> we do.
> I definitely agree. Having some common ground would be great. Agreeing on
> the API level sure will get very technical. Having the same Metadata format
> would definitely ease the integration step of different C++ framework a lot.
>>> Does anyone have any ideas/suggestions regarding this? What would be a
>>> good
>>> starting point?
>> Getting in touch, getting a discussion going. Perhaps we should write up a
>> small introduction to Celix, maybe even a short demo video, that shows what
>> Celix can do, contact these projects on their mailing lists, forums, etc.
>> and see what happens.
> You got my attention already :-) I don't know if that is feasible, but
> having something like a one-day brainstorming meeting in real life would
> definitely get things rolling much faster. The main developers of the listed
> C++ OSGi projects are all living in Germany and the Netherlands are not so
> far away. If people are interested, maybe there is an opportunity to meet...

Good idea. I also think it would be wise not to wait to long with
this, so maybe its possible to arrange something the first half year
of 2012 ?

>>> Also I think it is interesting how the current Celix framework can be
>>> extended so that it can support C++. If possible I would like to keep a C
>>> only framework, with specific extensions if used with C++.
>> Agreed.
> Yes, AFAIK that is exactly how other projects are doing this. The C library
> is untouched, and a separate C++ library/framework just provides a thin
> object-oriented API layer on top. Shouldn't be too hard to do. And the huge
> advantage of having a native C API is that generating other language
> wrappers is much easier.

Maybe a step to far, but isn't a idea - instead of just adding a C++
wrapper - to develop Celix as a SOA framework where C and C++
services/bundles can be transparently combined? In other words
services - written in C or C++ - should always expose a C and C++
interface. This way Celix could be an interesting framework for
projects which want combine C and C++ without resolving to extern "C"

> Greetings from Heidelberg,
> Sascha

View raw message