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