celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael de Lang <o...@apache.org>
Subject Re: Positioning Celix against CppMicroservices, a C++ OSGi implementation
Date Wed, 19 Aug 2020 20:55:49 GMT
Hey Pepijn,

Thanks for taking the time to thoroughly answer.

On 2020/08/16 20:21:47, Pepijn Noltes <pepijnnoltes@gmail.com> wrote: 
> 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.

Ah, yeah, it's quite a big difference and it would require both sides to want to implement
more or less the same thing in both languages. Would you say that the current status of CppMicroservices
still seems like it adheres less to the specification? The bundles listen on their website
(http://cppmicroservices.org/) as well as the ability to make zips and embed resources (http://docs.cppmicroservices.org/en/stable/framework/doc/resources.html)
make it look like it follows it relatively well. Or was the difference never that pronounced?

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

Hmm, while I do think that celix offers a lot for the C language, I'm still on the fence when
it comes to providing both a C and a C++ API from the same library. Rather, I have the suspicion
that making them compatible on the network layer (so seamless use of RSA and  pubsub) is all
that is needed. This would mean two separate libraries, but both catered well to the language
they aim for.

Also, while C is stable and 'small', mastering the language takes a long time: the language
doesn't prevent you at all from shooting yourself in the foot ;)

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

I generally agree with your points and you raise a good one as well: coming from the OSGi
specification and moving to another language, libraries that lower the learning curve would
be favourable. However, and this is specifically targeted to the OSGi Promise & Pushstream
spec, some parts of the spec are, IMO, very outdated. The trend in modern languages to add
for example coroutines (or more commonly known as async/await), is in the general case a superior
solution. Although promises are easy to use with coroutines, it should generally be discouraged
to use promises without them. I can't really think of any situation where a promise on its
own would be preferable. However, this would obviously cause a disconnect between what a user
from another OSGi implementation is familiar with. Moreover, it is a deviation from the OSGi

I guess what I'm trying to say is, how much should one really go for familiarity over improvements?
I don't have an answer yet, I need some more time to think about it. For a C library I can
imagine staying with the OSGi spec, as while coroutines libraries are available for C, I don't
know if I would personally use them in C. For a pure C++20 library, I would prefer to encourage
users to use coroutines on top of discouraging users to use standalone promises. But then
making a C API around that C++20 library would become rather difficult. It is rather difficult
to fully understand the consequences of these choices.

Yours sincerely,

View raw message