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] Celix Roadmap & Future Celix vs OSGi
Date Mon, 10 Jul 2017 19:20:02 GMT
Hi All,

Thanks for the comments.

On Wed, Jul 5, 2017 at 7:21 PM Gabriele Ricciardi <lele.ricciardi@gmail.com>
wrote:

> Hello all,
>
> Here are my 2 cents about the API change proposal.
> I would also join the big thank to Pepijn for writing down this proposal
> with useful details and explanations.
>
> When expressing my opinion, I speak as Celix core developer but also as
> Celix user.
>
> Celix is an "OSGi compliant" framework, and following the OSGi spec should
> be one of the focuses of the project.
>
> On the other hand, the C nature forced us to deviate from the spec (that's
> explicitly written for Java), simply because C does not have mechanisms
> such as the reflection.
> So, since Celix is already not fully OSGI compliant, further deviations
> should not be a problem, especially when those deviations come for the sake
> of performance, robustness and usability of the framework.
>

I agree that further deviations from the OSGi should not be a problem, but
I am not sure how far we should deviation.

For example in the current API proposal, I removed the bundle context as a
primary way to setup services / service dependencies. Instead a module
object can be used. One reason is that I am personally not a fan of the
naming of "BundleContext"; you are programming a module and the context
part is not really needed.. but that is my 2 cents and on it self not a
good reason. The second reason is that if we are going to deviate from the
OSGi api, I think a more obvious deviation should help understanding the
framework and more specifically the differences with a Java (garbage
collected) API. Lastly as already mentioned I think the OSGi API is not
very consistent (e.g. register service with bundle context, but unregister
with service registration ...).

Or put in a coding  example, register & unregistering service from:
bundleContext_registerService(context, ..., &svcReg);
serviceRegistry_unregister(svcReg); //note register with bundle context,
unregister by service registration.
to:
uint64_t svcRegId = celix_module_registerService(module, ...);
celix_module_unregisterService(module, svcRegId);

creating a service tracker from:
//create customizer
serviceTracker_create(context, svcName, customiser, &tracker); //note
tracker used bundle context, but is not called through the bundle context
as with getServiceReferences
serviceTracker_open(tracker);
serviceTracker_close(tracker);
serviceTracker_destroy(tracker)
to:
celix_service_tracker_options opts = {0};
//use opts to setup callbacks
uint64_t trackerId = celix_module_trackServiceWithOptions(module, &opts)
celix_module_stopTracker(module, trackerId);

Any thoughts how far we should or should not deviate - and why - are
welcome ;)


>
> Celix improved really a lot in the last years, and components like the
> Dependency Manager and the DFI library really make life easier for
> programmers, compared to the past.
> Usage of those components should be recommended and encouraged: in this
> sense, simplifying the API giving access to only a certain set of functions
> will help.
>
> As Celix user, sometimes I found the API a bit confusing, especially when
> dealing with serviceReferences and similar: that's why I think that
> excluding those functions from the API is not a bad idea, even because they
> are well "masked" by the existing mechanisms.
> A clean, lightweight (and well documented, maybe creating something similar
> to JavaDocs can be an idea...) API helps enormously, in particular when
> getting in touch with Celix for the first time.
>
>
> Just to conclude, I think the right is in the middle: removing from the API
> superfluous functions is a good idea, on the other hand we should still
> give access to some of the "low level" mechanisms(e.g. serviceRegistration,
> serviceTracker and listenerHook).
>

Ok, maybe an idea to integrate the dependency manager in the framework api
for the next (2.1) release?


>
> In this way, beginners are encouraged to use DependencyManager, Components
> and ServiceDependency, and advanced users that needs "something more" from
> the framework can still keep on using the "low level" API.
>
> Note that this is exactly what happens with more famous libraries (e.g.
> libcurl): they have an "easy" interface, but also an advanced one for more
> complicated stuff.
>
>
> I hope the discussion will go on and at the end we get something that
> really encourage Celix usage from the community!
>
> Greetings,
>
> Gabriele
>
> P.s. Personally, I find the support for minimalistic OS proposal from
> Gerrit very interesting: due to the lightweight runtime and the
> performances, I think Celix is really suitable for usage in embedded
> systems (and as you probably noticed, we got this interest expressed in
> some messages to the mailing list). Support for that kind of platforms may
> even boost Celix popularity!
>
>
>
> 2017-07-02 21:09 GMT+02:00 Gerrit Binnenmars <gerritbinnenmars@gmail.com>:
>
> > Hello all,
> >
> > Here is my (hopefully not too long) comment on the proposed API changes
> of
> > Pepijn. First of all, thanks to Pepijn for this roadmap proposal.
> >
> > *Object sharing:*
> > In my opinion the focus on minimizing object sharing and resource
> > protection is for any language and not restricted to C
> > In general I agree with the idea of resource ids (handles) for sharing
> > data. Keep in mind that is has a performance drawback.
> > Further it does not yield any real additional safety if the users can
> still
> > retrieve the underlying object.
> > In my opinion, the goal shall be to use only (!) resource ids in the API.
> >
> > *OSGI API leaks too much details*
> > The discussion should focus on what the set of functions is that
> currently
> > is in use by users of Celix. So could we offer a simple API for first
> time
> > users and keep the complete API for experiences users?
> >
> > *Single framework event thread.*
> > I doubt if this is really needed with a good implementation of resource
> > locks. It is not a work-around that has serious performance drawback
> > *Focus on primary way to interact with the dynamic service framework*
> > Completely agree with this, good point!
> >
> > *Error codes*
> > Not completely recognizable from the API what your proposal is here
>

Basically not returning an error code if you cannot do something useful
with it.
I.e. log, but do not return error code if an unregister service fails.
And always ensure that calls are save even if the provided arguments are
NULL or invalid ids.
e.g. module_unregisterService(NULL /*should be module*/, 42); should log an
error, but not crash and also for module_unregisterService(module, 42
/*invalid id*/);



> >
> >
> > *DFI*
> > Agree that this shall be an option. Is this your own argument that One
> API
> > for all is not realistic?
>

I am not sure what you means with this. Could you elaborate?


> >
> > *Event admin*
> > Although this is a roadmap idea, I am not convinced. If really needed
> there
> > would be more focus on the current EventAdmin implementation.
>

Correct it is not needed, but I do think that, for example, the RSA
implementation could be less complex using an event admin; specifically the
communication between topology manager & discovery.


> >
> > *Prefix*
> > Personaly I prefer the celix_ prefix
> >
> > *Descriptors*
> > Make clear that these are also optional
>

Yeah, correct should also be optional.


> >
> >
> > *Conclusion*
> > The above API proposal is a very good proposal that leaves sufficient
> room
> > for discussion. Lets start this discussion a bit more to make it a
> > community roadmap!
> > This API focusses very strongly on simplifying use. I would like that the
> > roadmap also focusses on other items. I have a few proposals:
> > - support a really minimalistic operating system, e.g. FreeRTOS, to get
> > more embedded system/IoT attention
> > - roadmap / release schedule for modules in Celix that are not part of
> the
> > current releasse (e.g. ConfigAdmin, EventAdmin, Remote services)
> > - other missing OSGi specs?
>

Ok thanks for the input. The proposed API covers a lot of the current
roadmap items [2].
But I welcome other roadmap items.
+1 for the FreeRTOS idea.. but it is as far as I can tell an (modified) GPL
license and
+1 the for the event admin.

Maybe also start looking at HTTP service (chapter 102) and declarative
services (chapter 122) ?

2: https://github.com/apache/celix/blob/develop/documents/roadmap/roadmap.md



> >
> > Greetings Gerrit
> >
> >
> >
> > On Fri, Jun 30, 2017 at 4:38 PM, Pepijn Noltes <pepijnnoltes@gmail.com>
> > wrote:
> >
> > > Hi Jan Willem,
> > >
> > > On Fri, Jun 30, 2017 at 12:30 PM Jan Willem Janssen <
> > > janwillem.janssen@luminis.eu> wrote:
> > >
> > > > Hi,
> > > >
> > > > Just out of curiosity, what exactly do you envision with the new API?
> > Do
> > > > you have some example on this. It makes the discussion perhaps a
> little
> > > > easier to get started on whether or not it is a good way forward...
> > > >
> > >
> > > I agree. I actually added a proposed API (in a single header) to the
> > > development branch a few days ago [1].
> > > I have been tweaking and editing this proposal for quite a while and
> > > personally think it is very complete. I also think it is a big
> > improvement
> > > on the current API.
> > >
> > > I wasn't sure how to bring this to the mailing list, because - as said
> -
> > it
> > > is a very complete API proposal and as result fairly lengthy. So I was
> > > thinking about splitting it up a bit and removing some details, but
> since
> > > you asked ... :).
> > >
> > > The intro sums up a list of reasons why I think a API / design change
> is
> > > IMO needed and is a good starting point. The proposed header file also
> > > introduces some framework services near the end of the file.
> > >
> > > @all: Please feel free to look into this and comment on the proposal.
> By
> > > mailinglist or with use of pull requests.
> > >
> > > [1] https://github.com/apache/celix/tree/develop/documents/
> > roadmap/api_v3
> > >
> > >
> > >
> > >
> > > >
> > > > > On 8 May 2017, at 22:13, Pepijn Noltes <pepijnnoltes@gmail.com>
> > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I took the liberty to setup a roadmap [1] for Apache Celix based
on
> > > > > the improvement ideas. This is just an initial setup and should
> > > > > considered an input for discussion not a final roadmap.
> > > > >
> > > > > [1]
> > > > https://github.com/apache/celix/blob/develop/documents/
> > > roadmap/roadmap.md
> > > > >
> > > > >
> > > > > In this roadmap I also added plans for changing the core API of
> > Apache
> > > > > Celix (3.0.0 release).
> > > > >
> > > > > As most of you probably know, Apache Celix is heavily based on the
> > > > > OSGi specification. For Apache Celix we created a mapping between
> the
> > > > > Java API and C variant, and this really helped us getting Apache
> > Celix
> > > > > up and running.
> > > > > But I also think that the OSGi API (note that OSGi started more
> than
> > > > > 15 years ago) is not really modern nor user friendly. More bluntly
> it
> > > > > is IMO overly complex; It leaks unnecessary details and requires
> more
> > > > > calls then really necessary.
> > > > >
> > > > > This has become more obvious for me in the last year, because I
> > always
> > > > > prefer and refer to use the Apache Celix Dependency Manager instead
> > of
> > > > > the ported OSGi API. This is also true when I program with Java
> > > > > (Apache Felix Dependency Manager).
> > > > > Now I know OSGi is a specification and in a way it would be wise
to
> > > > > follow this, but honestly I think the Java API really needs an
> > > > > overhaul and for native (e.g. no garbage collect) languages I think
> > > > > the OSGi API is a mismatch. Changing the API will not only benefit
> > the
> > > > > usability, but should also result in a smaller code base ... less
> > > > > complex, more maintainable, probably less bugs, etc.
> > > > >
> > > > > An example:  If a service is removed in Apache Celix, it's
> allocated
> > > > > memory is also deallocated or worse reused for a different purpose.
> > In
> > > > > my knowledge this is not the case for Java services (the garbage
> > > > > collector will keep the service intact even if the bundle is
> > removed).
> > > > > Combine this behaviour with the "default" way of getting services
> > > > > (bundleContext.getServiceReference(s) -> bundleContext.getService)
> > and
> > > > > with no support for locking this is a disaster waiting to happen.
> Now
> > > > > I know there are ways around (service trackers) and these are even
> > the
> > > > > preferred way, but this IMO also means that there should be no
> > support
> > > > > for getting services through the bundle context, nor should a user
> > > > > need to know about service references.This combined with an API
> with
> > > > > could be much cleaner has me leaning in the direction to refactor
> > > > > Apache Celix for "easy" use of dynamic services but without using
> the
> > > > > ported OSGi API.
> > > > >
> > > > > Note that I do not expect that we change Celix this drastically is
> > the
> > > > > near future, so this is more to start the discussion where Celix
> > > > > should be headed in the future.
> > > > > And although I think this is not really possible without being a
> > > > > member of the OSGi alliance, maybe working on a more modern Native
> > > > > OSGi spec/API?
> > > > >
> > > > >
> > > > > Well that my 2 cents, please feel free to comment ... or agree ;)
> on
> > > > this.
> > > > >
> > > > >
> > > > > Greetings,
> > > > > Pepijn
> > > >
> > > > --
> > > > Met vriendelijke groeten | Kind regards
> > > >
> > > > Jan Willem Janssen | Software Architect
> > > > +31 631 765 814
> > > >
> > > >
> > > > My world is something with Amdatu and Apache
> > > >
> > > > Luminis Technologies
> > > > John F. Kennedylaan 32
> > > > 7314 PS  Apeldoorn
> > > > +31 88 586 46 25
> > > >
> > > > https://www.luminis.eu
> > > >
> > > > KvK (CoC) 09 16 28 93
> > > > BTW (VAT) NL8170.94.441.B.01
> > > >
> > > >
> > >
> >
>

Greetings,
Pepijn

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message