celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerrit Binnenmars <gerritbinnenm...@gmail.com>
Subject Re: [DISCUSS] Celix Roadmap & Future Celix vs OSGi
Date Sun, 02 Jul 2017 19:09:36 GMT
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