|Alexander Broekhuis||Jan 10, 2012 10:30 pm|
|Marcel Offermans||Jan 10, 2012 10:55 pm|
|Pepijn Noltes||Jan 11, 2012 12:04 am|
|Martim||Jan 11, 2012 4:32 am|
|Sascha Zelzer||Jan 11, 2012 4:41 am|
|Sascha Zelzer||Jan 11, 2012 5:38 am|
|Alexander Broekhuis||Jan 12, 2012 2:15 am|
|Pepijn Noltes||Jan 13, 2012 2:24 am|
|Marcel Offermans||Jan 13, 2012 10:13 am|
|Marcel Offermans||Jan 13, 2012 10:23 am|
|Sascha Zelzer||Jan 17, 2012 12:56 pm|
|Pepijn Noltes||Jan 18, 2012 12:53 am|
|Alexander Broekhuis||Jan 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|
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
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
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++.
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,