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'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? 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.
