atom feed13 messages in org.apache.incubator.celix-devRe: Poddling status
FromSent OnAttachments
Alexander BroekhuisJan 10, 2012 10:30 pm 
Marcel OffermansJan 10, 2012 10:55 pm 
Pepijn NoltesJan 11, 2012 12:04 am 
MartimJan 11, 2012 4:32 am 
Sascha ZelzerJan 11, 2012 4:41 am 
Sascha ZelzerJan 11, 2012 5:38 am 
Alexander BroekhuisJan 12, 2012 2:15 am 
Pepijn NoltesJan 13, 2012 2:24 am 
Marcel OffermansJan 13, 2012 10:13 am 
Marcel OffermansJan 13, 2012 10:23 am 
Sascha ZelzerJan 17, 2012 12:56 pm 
Pepijn NoltesJan 18, 2012 12:53 am 
Alexander BroekhuisJan 23, 2012 1:09 am 
Subject:Re: Poddling status
From:Pepijn Noltes (
Date:Jan 18, 2012 12:53:20 am

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++.


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" constructs.

Greetings from Heidelberg,