celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: [DISCUSS] C++ Celix Framework
Date Tue, 29 Jan 2019 20:39:11 GMT
Hi,

Sorry fo the late reply.

Thanks for you input. I agree with a lot of points and will think
about it. I expect I will pick some ideas for the roadmap update.

For now I think it is most wise to park the C++ framework and focus on
getting a new Celix release out.
I will try to get a mail soon to discuss what steps I would like to
make before making a new release.

After that I think we should include the C++ framework and - for a
while - also keep the C framework.
Ensure that the C++ framework in API compatible with C implementation
and - as suggested - start creating performance tests so that we can
create a clear overview of the performance of the different
frameworks.
I my opinion the performance test should focus on the service
retrieval from the service registry with ~ 1000 or more services and
invocation overhead for tracked services. For services this includes C
structs (as is now supported), (Smart) pointers to abstract classes
(i.e. virtual methods) and std::function services.

I do like to idea to put some effort in to make Celix and Celix
bundles available in some packet managers.
IMO for this to really work for Celix a few steps are still needed:
 - Remove the need for a .cache dir. Only use this when configured
else use a process id cache somewhere in /var/lib/celix/cache/${PID}
or ${HOME}/.celix/cache/${PID}?
   This to make it possible to run celix application anywhere not
necessary in a specific dir. So more like a "normal" application.
   Clean shutdown op the Celix framework shut clear the cache and
celix startup show check if there are caches which can be removed
(i.e. pid not valid anymore).
 - (Indeed) Support for features (group of bundles)
 - Add startup option to list available bundles / features and option
to add/remove startup bundles/features to the framework.

Greetings,
Pepijn

On Fri, Jan 11, 2019 at 10:09 PM Miroslav Beranič
<miroslav.beranic@mibesis.si> wrote:
>
> Hi,
>
> I am not against C++, just because of the language. I am just questioning -
> what are the benefits. Is it worth the effort, put into it. I guess a
> relevant benchmark/metric data would make such decision easier.
>
> I am mostly comparing Celix to Karaf, but I would have to compare it
> against Felix, I guess. As far as I know, even Karaf/Felix was once one
> project, that broke into separate projects, each with a dedicated
> focus/goal.
>
> For Karaf I know few big companies that use Karaf in their product lineup,
> and as such I know what are the design goals, what are the focus areas.
> With Celix I do not have such a clear picture.
>
> With that said. What I meant with additional features was ( and I guess
> some are not "core" Celix features ) things like: support for group package
> deployment, like Feature in Karaf - list of bundles with dependencies and
> dedicated repository for dependencies. For Celix it would be really neat if
> apt/yum repositories could be re-used ( I guess there are other, newer
> package managers out there, but most of my work is around RHEL 7.5/8 and
> Ubuntu Linux ). Again, as I do not know the goal/focus for Celix, I do not
> know if appropriate or not, but things like Cellar would be awesome to have
> - where one could easily distribute package deployment among nodes. Out of
> the box support for REST queries for deployed bundles and "simple"
> deployment/management API. Support for bundles in other language - for
> example, write Java class / bundle with activator ( support for Java-based
> OSGi spec ) and wire into Celix - use other/exiting services. In my design
> I would implement such solution in connection with ASN.1 description of the
> interfaces ( or some other "low level" data protocol ) - something like (
> or exactly like ) FastWebservices (Defined in ITU-T X.892 | ISO/IEC 24824-2
> ). I guess, this would not be really performance best job, as no one can
> avoid JNI penalty, but if someone needs it - it can benefit from it. One
> other thing is to make it compile/run on as many hardware/OS platforms as
> possible and promote the solution to projects like HEMS, SmartGrid, energy
> trading platforms, etc ( this are the fields I know, so I guess other
> related could also benefit ). Nowadays all sort of such solutions are
> written in PHP, Java, C#, JS or what ever new language someone thinks out
> this days.
>
> Celix is like core of the "module platform", but I guess core is OK, but
> project needs ecosystem around it, that builds on top of the
> benefits/features provided. My goal for sure is to "grow" Celix in a path
> like "big boys", for example as Karaf. I know I am "mixing projects" a bit,
> but pure OSGi implementation is not usable on its own -- it needs usecases
> and provide solid solutions/alternatives. In my early PoC projects, for
> same functionality I can outperform Karaf-based solution for around 100x --
> in the same time Celix/C can serve 100x more clients or 100x more packages,
> but to be able to compete all the surrounding ecosystem needs to exist (
> integrated deployment, integrated clustering, integrated etc ). As it is
> now, it is not cost effective to go in that direction, no one will approve
> such a route.
>
> I am sure someone needed Celix and at that time, there must be some "goal
> roadmap", what is the purpose to build Celix. I guess it was not for fun to
> implement OSGi in C. No one can have so much time, to have fun, I guess C
> is one of the last languages someone picks to make things modular and
> dynamically deployable in runtime ( I was referring to application
> landscape, not kernel modules etc).
>
> Other thing is, that I did not have Celix application running for non-stop
> over long period of time in production. So I can not really comment on
> stability, but for what I was testing it was working quite stable and did
> not run into any crash - from Celix, it crashed from inside one of my
> bundles. I did not even dive deep into Celix, I did at the begging, but not
> ever since. I guess over time, every project has heavy weights that could
> be cut out.
>
> But this is thread related to C++, so I went out of the topic focus. So my
> "final" comment on the subject is: if C++ based implementation has benefits
> and has similar or better characteristics compared to existing code base I
> am all for it, but to me C is really fun language, that if treated with
> love in can do whatever new-age language can do.
>
> And not to forget: existing work is really nicely put together and congrats
> to all the authors.
>
> Kind Regards,
> Miroslav
>
>
>
>
> V V čet., 10. jan. 2019 ob 21:54 je oseba Pepijn Noltes <
> pepijnnoltes@gmail.com> napisala:
>
> > On Wed, Jan 9, 2019 at 3:39 PM Gabriele Ricciardi
> > <lele.ricciardi@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > as for many things, in my opinion there are many pros and cons in moving
> > to
> > > a C++ implementation of the framework.
> > >
> > > I discussed the subject with Pepijn already few times, and he has many
> > > points: C++ is a popular language, and offering support for it will
> > surely
> > > give more visibility to the project and also give more opportunities to
> > the
> > > end developers for choosing Celix as base framework for their
> > applications.
> > > I can agree on some technical arguments like type safety and smaller/more
> > > compact code base that may increase the maintainability.
> > > I also understand that using some of the modern C++ construct can make
> > life
> > > easier when it's about implementing core parts of the framework.
> > > Moreover, I also think that introducing C++ support may open new horizons
> > > for "pure" C programmers (like me).
> > >
> > > I'm not really concerned about the possible stability issues we may
> > > encounter, Celix got pretty stable in the last few years and I don't see
> > a
> > > reason why a different implementation can't reach the actual level of
> > > stability (or even better).
> > >
> > > What concerns me a bit more is the possibility of eventually dropping the
> > > support for C: of course the current implementation should (or better,
> > has
> > > to) improve, but honestly I think that arguments like RAII and error
> > > handling are not sufficient to justify such a swift direction change.
> > >
> > > As Miroslav pointed out, C is a bit more verbose but is also very stable
> > > throughout years, the code is (in my opinion) more readable and, if well
> > > written, it is portable and not really error-prone: basically, I agree
> > with
> > > C being a "holy grail" and as developer I would always like to have the
> > > opportunity to play that card.
> > >
> > > For those reasons I think that moving and concentrating only on C++ and
> > > just provide a "(mostly) backwards compatibility C API" (for eventually
> > > phasing it out) would be a real pity.
> > >
> > > In my opinion, support for C and C++ should get the same attention and
> > try
> > > to provide (as far as allowed by the specific language) the same
> > > functionalities: in the end, I don't see a problem in keeping up with two
> > > implementations, even if one will be a bit more verbose or slightly
> > harder
> > > to code (of course, benefits should always outweigh or at least balance
> > the
> > > efforts, so if a new feature is easy to implement in C++ and nearly
> > > impossible to implement in C... well, it will be unsupported for C).
> > >
> > > On the contrary, I do see the benefits of keeping up with two
> > > implementations: we can really provide a flexible framework that gives
> > the
> > > end developer the possibility to choose what he thinks it' better for him
> > > and his application. Of course it will require a bit more effort on our
> > > side, but I see it as a good opportunity to bring Celix to the next
> > level.
> >
> > I have not though about maintaining a C and C++ version and my first
> > reaction is that we should not do this, but
> > to be honest I have to think about this.
> >
> >
> > >
> > >
> > > Kind regards,
> > >
> > > Gabriele
> > >
> > > Il giorno mer 9 gen 2019 alle ore 09:29 Miroslav Beranič <
> > > miroslav.beranic@mibesis.si> ha scritto:
> > >
> > > > Hi all,
> > > >
> > > > I've started working with Celix back at 2015. At that time, I as "all
> > about
> > > > C++" and thought about C as "C++ predecessor that will fall out", so
> > C++
> > > > was obvious was forward. With use of Celix, I've started to see
> > solutions
> > > > implemented in C that at that time I thought "only possible in C++".
> > With
> > > > time, I've dropped C++ all-together as to my opinion, C++ standard is
> > > > moving to fast to radical. For example, Google C++ Style Guide advice
> > on
> > > > the C++ is:
> > > >
> > > > " Currently, code should target C++11, i.e., should not use C++14 or
> > C++17
> > > > features. The C++ version targeted by this guide will advance
> > > > (aggressively) over time.
> > > > Code should avoid features that have been removed from the latest
> > language
> > > > version (currently C++17), as well as the rare cases where code has a
> > > > different meaning in that latest version. Use of some C++ features is
> > > > restricted or disallowed. Do not use non-standard extensions."
> > > >
> > > > Over time I've started to appreciate the simplicity of C ( this does
> > not
> > > > mean it is less capable ). With C++ there is so many hidden things
> > > > generated, it starts to feel like Java. One note here: my day-to-day
> > job is
> > > > around Apache Karaf, Camel, JMS, ... enterprise integration; but more
> > and
> > > > more I am thinking about porting ( step by step ) from existing bloated
> > > > environments where all I want is move data from one end to another to
> > > > simple & fast - like Celix. But here, yes - there is a lot of missing
> > > > components that Java based "OSGi implementation" counterpart already
> > has.
> > > > And it would make ( financially ) no real benefit -- no one will
> > approve
> > > > such a project to me.
> > > >
> > > > In my "night time" job I use Celix since day one of using Celix. All I
> > want
> > > > from Celix is that it is simple and runs super fast ( and for sure
> > stable
> > > > ).
> > > > @Pepijn, you might do not remember that I wrote about C++ back in
> > 2015. You
> > > > wrote back:
> > > > "I think support bundles written in other (native) language is quite
> > > > feasible. I even started prototyping with some Swift code (which is
> > > > promised to become open source) . The beauty about C is that it is the
> > > > common dominator for native languages and therefore ideal as core
> > framework
> > > > language.
> > > > The biggest challenges would be how and if those bundles can share
> > services
> > > > written in different language. So cpp pure abstract class as service
> > used
> > > > in a C bundle ??
> > > > Note that this is my opinion and not _the_ Celix policy, everything is
> > > > discussable."
> > > >
> > > > At that time I really started to thing about C as common nominator.
> > Now I
> > > > have same code base ( with some obvious differences ) running on
> > Arduino,
> > > > Android, RaspberryPI ( Yocto project ) and WebAssembly ( all about
> > moving
> > > > data from one end to another using ASN.1 ). To me C is holy grail. It
> > does
> > > > have more verbose syntax and it does not all the compile-time checking
> > as
> > > > C++ does ( a lot has void* ), but it produces a lot smaller/portable
> > code.
> > > > I agree also, this is possible also because I do not know all the
> > latest
> > > > bells and whistles from C++. To me C++ is like moving target. It is
> > modern
> > > > now, in 5 years time we are talking about "old" C++. With C, code base
> > from
> > > > 15 years ago works and documentation is valid.
> > > >
> > > > At the and I agree someone will start to implement C++ "version of
> > Celix"
> > > > as this is reality. I also agree this should be Celix community, not
> > some
> > > > outside community. I would also argue that there should be only C and
> > only
> > > > C++ implementations as from my experiences, mixing C and C++ is
> > useless. It
> > > > does not have C way of work, it does not have C++ way of work. And C++
> > is
> > > > not "just" C with classes. I do agree C++ has benefits, but we all
> > should
> > > > know what those benefits are. Also what is the goal of Celix, what is
> > > > roadmap. Is this even an option?
> >
> > Well said and I agree with this - especially, because you also quoting
> > me... ;).
> > Specifically the fast movement of C++ language - although that also
> > has it benefits - is indeed a real concern.
> > This combined with the idea that C++ is a "expert friendly" language,
> > creates a risk that the code can become "old" quickly and as result
> > inverse the maintainability.
> >
> > I also still think that C is the more clean and elegant language and
> > that it is also the common nominator to expand to other languages.
> > The thing is, that the common nominator part can be done by providing
> > a C API from a C++ implementation and maybe I see this incorrect, but
> > I do think the combination (with effort) of C/C++ is feasible.
> >
> > When I started working on the C++ implementation I was quite surprised
> > at the progress I was able to make (and for that reason, I probably
> > took this experiment to far before discussing this) and
> > combining this with ability to create a more concise user API and the
> > popularity of C++ is the reason I think we should really consider
> > this.
> >
> > To be clear If the general consensus it that we should keep the focus
> > on C I have no problem with. I enjoy writing code in C and I also
> > agree with Gabriele that - if done well - C delivers very readable
> > code (it just requires lots of lines of codes .. ).
> > My point is that the goal of Celix is what we as community make of it
> > and to keep Celix relevant I have no problem changing this when needed
> > (e.g. more or less strict on OSGi or implemented in C or C++).
> >
> >
> > > >
> > > > What I am missing from Celix is added functionality. At the end do not
> > > > really care C or C++, as long as the metrics are what is expected.
> > > >
> > > > Regarding my metrics data questions, my wife was recently awarded PhD
> > > > regarding measuring metrics in software, so I am all about metrics this
> > > > days. Did not plan to be "rude" or anything. Main point was - is it
> > > > possible to measure benefits of going forward with C++ or not. Is this
> > data
> > > > showing better results or not? Would new/better/updated version of C
> > > > implementation yell better results? If we can put scale and values on
> > that
> > > > scale, decision would be easier. To me it is all about code size it
> > > > produces and speed it executes ( with stability).
> >
> > No worries. I did not think it was rude and I am actually happy with
> > the feedback/comments.
> > And metrics would indeed be welcome, but is just something we have not
> > put effort in.
> >
> > > >
> > > > With languages I was thinking about Lua ( not really programming
> > language,
> > > > but hey ... ), Rust, Dart, Java. I guess most of this can be solved
> > with
> > > > bindings.
> >
> > Ok thanks, I was just curious. I know there has been no real progress
> > on other languages  - well except C++ ;) -, but this is something I
> > still really would like.
> > There is btw hopefully a window on my "day job" to pursue support for
> > Python,
> >
> > > >
> > > > To close this one: Go with C or C++, but do not mix. If core needs to
> > be
> > > > updated it would be nice if it could be done in C ( in existing code
> > base
> > > > ). If C++ is taken, use it with all the features it has and not use it
> > as
> > > > C. In either way Celix needs more added functionalities ( with clear
> > goals
> > > > and roadmap ).
> >
> > Good point. I still think that the current core framework in not good
> > enough yet and as result are still focusing on refactoring the
> > implementation and API of the Celix framework.
> > But are there any specific features/functionalities you think Celix is
> > missing?
> >
> > > >
> > > > Kind Regards,
> > > > Miroslav
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > V V tor., 8. jan. 2019 ob 21:24 je oseba Pepijn Noltes <
> > > > pepijnnoltes@gmail.com> napisala:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Tue, Jan 8, 2019 at 7:13 PM Gerrit Binnenmars
> > > > > <gerritbinnenmars@gmail.com> wrote:
> > > > > >
> > > > > > Hello Pepijn,
> > > > > >
> > > > > > I am a bit concerned by this move. Introducing C++ in the framework
> > > > makes
> > > > > > Celix no longer a dynamic service framework for C.
> > > > > > I understood the support for C++ in the API, so C++ bundles
were
> > > > > supported,
> > > > > > but this is something different.
> > > > >
> > > > > Note that even if the framework is done is C++, we can still deliver
> > a
> > > > > C API - for the framework and for the services provided by the
> > > > > bundles.
> > > > > It does add a mandatory requirement to a C++(11) compiler and
> > > > > dependency to libstdc++.
> > > > >
> > > > > My concern here is that moving to C++ could (eventually) lead to
some
> > > > > bundles only provided/consuming a C++ API and shut out C support.
> > > > >
> > > > > > A lot of effort is put in the code quality and stability of
the
> > > > > framework,
> > > > > > does this work need to be done once more?
> > > > >
> > > > > I understand your concern, and yes of course recreating the framework
> > > > > will lead to some stability issues.
> > > > > I started experimenting with a C++ framework for two reasons; 1)
I
> > > > > wanted to tryout what features/concepts of C++ we should include
in a
> > > > > C++ API to make it more accessible for C++ users and 2) IMO the
> > > > > current implement/design of the Celix framework is flawed and as
> > > > > result we still run into stability issues. Those two issues combined
> > > > > are there reason there is now an experimental C++ branch.
> > > > >
> > > > > Wether we decide to move to C++ or not, I still think we need
> > recreate
> > > > > the celix framework.
> > > > > What if forgot the mention in the previous mail is that in the C++
> > > > > registry all registration/unregistration and the starting/stopping
of
> > > > > trackers are handled in registry and with use of ref counting &
async
> > > > > calls (future) to prevent deadlocks in the framework; this is
> > somewhat
> > > > > complex, but manageable. For the current celix implementation this
> > > > > partly done in the framework object, the service registry object
and
> > > > > the service tracker object and this combined with (no ref count)
> > > > > handling of services references & service registrations and a
lot of
> > > > > entanglement between those objects currently still leads to race
> > > > > condition / dead lock issues.
> > > > > This approach can also be done in C, but requires simple more lines
> > of
> > > > > code ...
> > > > >
> > > > > With the updated C API I also started cutting out some
> > > > > concepts/complexity we IMO do not need (service references, bundle
> > > > > archive, bundle revision, module, service listeners, service listener
> > > > > hooks, framework listener), with the idea to eventually drop those
> > > > > concepts. These concepts are already dropped in the current C++
> > > > > framework implementation.
> > > > >
> > > > > So moving forward with C or C++ we should IMO (eventually) go for
a
> > > > > 3.0 release with a more lean API, implementation and support for
> > > > > bundles as linkable shared objects.
> > > > > And this will lead to some stability issues, but for sure become
a
> > > > > more stable and maintainable framework in the end.
> > > > >
> > > > > >
> > > > > > My conclusion: I would prefer to keep the framework as is and
> > > > concentrate
> > > > > > on adding functionality.
> > > > > > A C++ framework implementation does not bring enough to Celix.
> > > > >
> > > > > Functionally I agree, but it does arguable result in less lines of
> > > > > code framework .. i.e. a better maintainability & productivity.
> > > > >
> > > > > > If you really want to continue this should not go into Celix
but
> > in a
> > > > new
> > > > > > Apache project.
> > > > >
> > > > > I do not agree. Yes it would introduce back incompatibility changes,
> > > > > but that does not make it a different project.
> > > > >
> > > > > >
> > > > > > I am quite curious what the rest of the community thinks.
> > > > >
> > > > > Indeed...
> > > > >
> > > > > >
> > > > > > Gerrit
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 7, 2019 at 11:19 PM Miroslav Beranič <
> > > > > > miroslav.beranic@mibesis.si> wrote:
> > > > > >
> > > > > > > Hi Pepijn,
> > > > > > >
> > > > > > > is there any metric data regarding performance, code size
etc -
> > > > > compared C
> > > > > > > and "new" C++?
> > > > >
> > > > > Code size I do not know, but is something we can measure.
> > > > >
> > > > > For performance I assume you mean the overhead of calling services?
> > > > > I have no metric for that .. although that would be nice.
> > > > >
> > > > > In my reasoning as long as you can still provide/consume pointers
to
> > C
> > > > > service structs (as with the current Celix framework) for C usage,
> > > > > there is no performance difference.
> > > > > And the goal of the C++ framework should be to still a) support a
C
> > > > > API and b) support C service struct. So there should be no change.
> > > > >
> > > > > For C++ usage there will be the overhead of dereferencing the
> > > > > std::shared_ptr and overhead of accessing a std::function / pure
> > > > > abstract C++ interface (i.e. virtual method).
> > > > >
> > > > >
> > > > > > >
> > > > > > > Is there any plan to support other languages ( using language
> > > > bindings
> > > > > ) ?
> > > > >
> > > > > A C API, conform the current updated (celix_* headers) C API, should
> > > > > IMO be added 'out of the box'. Any other languages you where thinking
> > > > > about?
> > > > >
> > > > > > >
> > > > > > > From my side, I would really like to see C version, but
I guess
> > C++
> > > > is
> > > > > > > "must have".
> > > > > > >
> > > > > > > Kind Regards,
> > > > > > > Miroslav
> > > > > > >
> > > > > > >
> > > > > > > V V pon., 7. jan. 2019 ob 22:25 je oseba Pepijn Noltes
<
> > > > > > > pepijnnoltes@gmail.com> napisala:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > The last weeks I put some effort in exploring the
benefits and
> > > > > > > > downsides of changing the primary language of Celix
from C to
> > C++
> > > > in
> > > > > > > > an experimental branch.
> > > > > > > >
> > > > > > > > As you probably already know Celix start around 2010
with the
> > focus
> > > > > on
> > > > > > > > a OSGi implementation in C;  following the Java OSGi
spec very
> > > > > > > > strictly. And IMO that was correct choice at that
time and
> > with our
> > > > > > > > given experience.
> > > > > > > > My current vision is that we should follow the concepts
of
> > OSGi and
> > > > > > > > where possible the nomenclature, but focus on delivering
a (as
> > much
> > > > > as
> > > > > > > > possible) easy to use dynamic services framework for
C/C++.
> > > > > > > >
> > > > > > > > IMO this also means that we should think about moving
to C++.
> > > > > Because:
> > > > > > > > a) With the concepts of C++11 we can create a much
easier to
> > use
> > > > and
> > > > > > > > hopefully also easier to develop/maintain framework.
> > > > > > > > b) More type safe
> > > > > > > > c) RAII; which really helps a lot in dealing with
volatile
> > services
> > > > > > > > and trying to keep track of which services are still
in use.
> > > > > > > > b) C++ is simply more relevant and popular, which
should help
> > in
> > > > > > > > getting more traction for Celix.
> > > > > > > >
> > > > > > > > To get the discussion rolling and for me to get a
feeling what
> > the
> > > > > > > > effect of moving to C++ would mean, I created C++
experimental
> > (but
> > > > > > > > functionally quite complete) Celix C++ framework [1].
> > > > > > > > And I would like some feedback/discussion if this
is an
> > improvement
> > > > > > > > for Celix or any remarks on the Celix C++ framework
> > implementation.
> > > > > > > >
> > > > > > > > There are a few interesting changes in the approach/design
of
> > the
> > > > C++
> > > > > > > > framework:
> > > > > > > > 1) There is a separate (static) Registry library [2],
which
> > > > delivers
> > > > > > > > the functionality to register/use/track (and TODO
listener
> > hooks)
> > > > > > > > services. This library, by design, can be used without
the
> > rest of
> > > > > the
> > > > > > > > framework. I designed the Registry library separate
to keep it
> > > > clean
> > > > > > > > of bundles lifecycle stuff.
> > > > > > > >    - ServiceRegistration/ServiceRegistry uses RAII
to make it
> > > > easier
> > > > > > > > in use, specifically for cleanup.
> > > > > > > >    - The registry also support registering std::function
as
> > > > services,
> > > > > > > > this seems logical for C++.
> > > > > > > >    - The service template argument is used to deduce
the
> > service
> > > > > name.
> > > > > > > >    - The concept of services versions is dropped.
I do think
> > > > versions
> > > > > > > > on API is important, but more in a distributed environment.
In
> > my
> > > > > > > > experience for Celix everything should be build against
the
> > same
> > > > > > > > service API's. Playing around with backwards compatibility
on
> > > > binary
> > > > > > > > level with C++ is just reasonable.
> > > > > > > > 2) The framework library [3].  Here the focus in on
the
> > > > BundleContext
> > > > > > > > api so that almost everything can be done through
the bundle
> > > > context
> > > > > > > > api.
> > > > > > > >   - It is now also possible to register "static" bundles.
These
> > > > > > > > bundles are installed on every created Framework object.
This
> > make
> > > > it
> > > > > > > > possible to register bundles with use  a
> > > > __attribute__((constructor))
> > > > > > > > decorated function. With support for "static" bundles,
bundles
> > can
> > > > be
> > > > > > > > created as shared objects, which "just work" if you
link
> > against
> > > > > them.
> > > > > > > > See the C++ Shell example [4]. IMO this is a much
.. much more
> > > > > natural
> > > > > > > > way to handle bundles in a C/C++ environment.
> > > > > > > >  - Support for zip bundles and dynamically loaded
shared
> > object -
> > > > > with
> > > > > > > > use a the bundle create, start,stop ..etc symbols
is still TODO
> > > > > > > >  - BundleActivator now work on the constructor/destructor,
i.e.
> > > > also
> > > > > > > > following a RAII approach.
> > > > > > > >  - There is no concept of a ServiceReference (same
as in the
> > > > updated
> > > > > C
> > > > > > > > api).
> > > > > > > > 3) Resources can be linked against a shared object
and in that
> > way
> > > > > > > > OSGi extender pattern concept can be used without
using zip
> > files
> > > > as
> > > > > > > > bundles. See the C++ Shell implementation as an example
(this
> > > > bundles
> > > > > > > > has a version.properties resource) [5].
> > > > > > > > 4) For now glog is used as logging framework.
> > > > > > > > 5) libzip is used to handle the zip files. Note that
resources
> > > > linked
> > > > > > > > against the shared object bundles are packed as a
zip file.
> > > > > > > > 6) googletest is used for testing.
> > > > > > > >   - It is also easier to test bundles, because the
test
> > executable
> > > > > > > > "just" has to link against the bundle shared objects
to make
> > them
> > > > > > > > available. See the tests of the C++ Shell bundle [5]
> > > > > > > > 7) For now there is no way to export/import (versioned)
shared
> > > > > objects
> > > > > > > > from other bundles. I personally do no think this
is really
> > needed
> > > > (I
> > > > > > > > never use it myself). I also think that this should
be solved
> > by
> > > > the
> > > > > > > > language itself (i.e. C++ Modules).
> > > > > > > > 8) As far as I can see it is possible to create a
(mostly)
> > > > backwards
> > > > > > > > compatibility C API from the C++ framework. As long
as we only
> > > > > support
> > > > > > > > the updated C API, i.e. the the celix_* headers.
> > > > > > > >
> > > > > > > > The C++ framework API has no documentation yet, please
be
> > aware. I
> > > > do
> > > > > > > > think that it should be clear enough for experience
users and
> > the
> > > > > > > > developers, but this is still a TODO.
> > > > > > > > Currently for C++ there is a Registry [2] library,
a Framework
> > > > > library
> > > > > > > > [3], a C++ Shell bundle [5],  a C++ Shell TUI bundle
[6] and a
> > > > single
> > > > > > > > example executable to run everything [4].
> > > > > > > > I also took some effort to ensure that the code coverage
> > result are
> > > > > > > > generated and somewhat respectable.
> > > > > > > >
> > > > > > > > My experience thus far is mostly positive. Fewer lines
of code
> > are
> > > > > > > > needed (duh), but also (mainly because of RAII) less
if else
> > > > branches
> > > > > > > > are needed / error handling is needed.
> > > > > > > > I do have some trouble arrange the code, because some
part
> > need to
> > > > be
> > > > > > > > in the header (template) or in Impl classes to ensure
a more
> > clean
> > > > > > > > user API and the rest is in the sources files.
> > > > > > > >
> > > > > > > > Please feel free to let me know what you think. Note
that this
> > is
> > > > > > > > still experimental and we will discuss how to move
forward
> > later.
> > > > > > > >
> > > > > > > > [1] feature/cxx branch (for the 807b88 .. commit):
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f
> > > > > > > > [2] registry dir:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/registry
> > > > > > > > [3]
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/framework_cxx
> > > > > > > > [4]
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/examples/celix-examples/cxx_shell_example
> > > > > > > > [5]
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell
> > > > > > > > [6]
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell_tui
> > > > > > > >
> > > > > > > >
> > > > > > > > Greetings,
> > > > > > > > Pepijn
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Miroslav Beranič
> > > > > > > MIBESIS
> > > > > > > +386(0)40/814-843
> > > > > > > miroslav.beranic@mibesis.si
> > > > > > > https://www.mibesis.si
> > > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Miroslav Beranič
> > > > MIBESIS
> > > > +386(0)40/814-843
> > > > miroslav.beranic@mibesis.si
> > > > https://www.mibesis.si
> > > >
> >
>
>
> --
> Miroslav Beranič
> MIBESIS
> +386(0)40/814-843
> miroslav.beranic@mibesis.si
> https://www.mibesis.si

Mime
View raw message