celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Positioning Celix against CppMicroservices, a C++ OSGi implementation
Date Sun, 16 Aug 2020 20:21:47 GMT
Hi Michael,


On Sat, Aug 15, 2020 at 10:41 PM Michael de Lang <oipo@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

Mime
View raw message