Hi Michael,
On Sat, Aug 15, 2020 at 10:41 PM Michael de Lang <o...@apache.org> wrote: > > It seems we've (or at least I have) missed the already existing > CppMicroservices (https://github.com/CppMicroServices/CppMicroServices) > framework, which aims to implement OSGi for C++14. Given our current > discussions/efforts into providing C++ API for Celix, we have a couple of > critical questions we need to ask ourselves. I know CppMicroservices. Back in - I think - 2012 we talked with the lead developer of CppMircoservices about a possible Native OSGI spec and a shared API. And although there was some effort to get this up and running this eventually fizzled out. IMO mainly because it is difficult to define a C and C++ API only library. The main differences between CppMicroservices (then) was that Celix uses C and CppMicroservices C++11 (which was fairly new then) and Celix more directly followed the OSGi specification. > > I've tried to assess the current situation, feel free to let me know if I > made omissions: > * Celix currently provides a partial implementation of OSGi, of which some > parts are not (yet?) implemented in CppMicroservices (pubsub, RSA) and some > parts are not in OSGi at all (etcdlib, iovec implementation). > * Both Celix and CppMicroservices both have one big commercial user (AFAIK): > Celix has Thales and CppMicroservices has German Cancer Research Center (DKFZ) > * Both Celix and CppMicroservices have similar order of magnitude of > activities outside of the main contributors (watches/stars/forks) > * There are currently two approaches at providing C++-esque support for what > Celix stands for. The experimental C++ API for Celix as can be seen in > Pepijn's PR (https://github.com/apache/celix/pull/259) and a more > revolutionary approach where OSGi is only used as an inspiration and adds > things like a clear threading model; Cppelix > (https://github.com/volt-software/cppelix). > > The questions we must then ask ourselves are as follows: > > * Do we believe a C implementation of the OSGi specification is a worthwhile > addition alongside other implementations such as CppMicroservices? > * Do we think it is worthwhile to offer a C++ API around Celix if other > implementations offer a native C++ API? Good point. My idea was always to create a Celix C++ library which also offers a C API. This library can co-exist - at least for a while - with the C library and create an option to seamlessly use Celix C bundles in a possible future Celix C++ framework. This is also a big reason why I think a C++ Celix library next to CppMicroservices has value. I think it is important to support a C api for two reasons: 1) (very simple) We already build a lot of Celix C Bundles (both on Apache Celix and commercial). This then creates an option to gradually (bundle per bundle) move from C to C++ (if this is desirable). 2) To support modularization of legacy C systems with a low entry point to start. This is maybe a stress, but I still believe Apache Celix is a good solution to modularize complex legacy system build with C. C is still heavily used and has two very big benefits over C++ ... it is a very stable and small language. > > If we honestly believe that providing a C++ API is the way to go, perhaps we > should consider the following two options: > * Joining forces/forking and implementing Celix functionality like the > stateless pubsub/RSA components in CppMicroservices > * Creating an evolution of the OSGi spec, such as Cppelix is an attempt at, > and focusing on that. > * Perhaps a third option that I haven't thought of yet > > Don't get me wrong, Celix is a product with lots of functionality in it that > isn't necessarily in the OSGi and is useful. However, I truly think that the > reality is that there are serious attempts in the world around us in making > similar products. We would do well to formulate a strategy with which we can > respond to these circumstances. A good point. I think you are correct that if we just implement a C++11/14/17 API this has no real added value compared to CppMicroservices. But I think cppelix is an interesting starting point for a possible future of Apache Celix. For a few different reasons 1) The OSGi framework spec does - almost - nothing to make multi threading programming more manageable, IMO a future Celix should address this. We are struggling with MT in the current Celix libraries/bundles and this adds unnecessary unstability and complexity. The cppelix framework tries to address this. 2) C++20. I consider the "pre C++11", C++11/14/17 and C++20 different languages, they change so much of the used programming paradigms that read as different languages. So a future Celix could be a C++20 framework with a C++20 API and a C API. The C++20 API can then use concepts, modules, "constexpr everything", coroutines, etc. This IMO would really create an added value for Celix, specifically if you can "just" start with C for the next few years and step over to C++20 when this is broader supported and more well known. One note though is that I would prefer that Celix tries to follow the concepts and especially the nomenclature of OSGi when possible. This should keep Celix being familiar for people with an OSGi background and should make it possible to very directly implement the OSGi compendium/enterprise spec parts. How I currently think about this, is maybe start with the OSGi Promise (we already started in this) & Pushstream spec and integrate this in the C++ framework library. So for example a service registration is returned as a promise to a service registration, chaining this promise can be used to do post registration actions on a well defined thread or thread pool. PushStream can be an integral part of the Framework and serve as a replacement for bundle listener, service tracker, listener hooks and even the event admin and a way to handle events in a thread confined manner. Greetings, Pepijn
