celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriele Ricciardi <lele.riccia...@gmail.com>
Subject Re: [DISCUSS] Celix Roadmap & Future Celix vs OSGi
Date Wed, 05 Jul 2017 17:21:03 GMT
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.

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

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
>
>
> *DFI*
> Agree that this shall be an option. Is this your own argument that One API
> for all is not realistic?
>
> *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.
>
> *Prefix*
> Personaly I prefer the celix_ prefix
>
> *Descriptors*
> Make clear that these are also 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?
>
> 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
> > >
> > >
> >
>

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