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:Sascha Zelzer (s.ze@dkfz-heidelberg.de)
Date:Jan 17, 2012 12:56:14 pm
List:org.apache.incubator.celix-dev

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: http://www-vs.informatik.uni-ulm.de/proj/nosgi/ - SOF: http://sof.tiddlyspot.com/ - CommonTK Plugin Framework: http://www.commontk.org/index.php/Documentation/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...

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.

Greetings from Heidelberg,

Sascha