On Tue, Jan 17, 2012 at 9:56 PM, Sascha Zelzer <[email protected]> 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: 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...
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" constructs. > > Greetings from Heidelberg, > > Sascha
