| Hi Pascal,
Now, claiming that Equinox is not suitable for IoT usage is erroneous and misleading. After all it has been used by Kura, SmartHome and others for years so it has to be good enough :)
Right, but „good enough“ is relative. For SmartHome, we have an overall OSGi startup time of at least 2 minutes on a RaspberryPi and a usual heap size of > 100MB. I cannot exactly split this up between the OSGi fw itself and the application on top of it. Nonetheless, for an embedded device this is quite huge and if there are possibilities to improve it, we are looking at it. Especially if you hear all the NodeJS folks talking about startup times on RasPis of only a few seconds…
So this is why Eclipse SmartHome is interested in Concierge. Not because it is a better solution than Equinox, but because it promises to reduce the footprint. If this is really the case and what compromise might come with that is something that we will find out on the way.
Another point why I think it is good to have a second OSGi fw at Eclipse is that the projects are forced to be put focus on compatibility with the OSGi spec. There are MANY projects that have a hard dependency on Equinox (e.g. EMF or Equinox DS), while they should only have a dependency on „some“ OSGi framework. This artificially reduces the popularity of these projects as they can only run on Equinox, but not anywhere else. This is something that the Felix guys do much better - most of their libs also run nicely on Equinox (and on Concierge!).
Just my two cents, Kai
Equinox and Concierge have been
designed with different goals in mind.
Equinox has been designed to handle systems made of a very large
number of bundles (like we have in IDE or RCP apps) which resulted
in a number of caching strategies to be implemented to improve
startup time, careful implementation of the service registry, all
of which increased the footprint of the fwk. Also equinox has a
number of extensibility mechanisms (e.g. interception of resource
loading, pluggable storage formats) and additional services like
Location.
As for Concierge, since its inception, it has been designed with
the goal of being the smallest OSGi implementation available.
Could those differences be dealt with by modularizing the Equinox
code base such that one could build a framework a la carte and
thus have a right-sized fwk ? Most likeky but who wants to pay for
this ? :)
Now, claiming that Equinox is not suitable for IoT usage is
erroneous and misleading. After all it has been used by Kura,
SmartHome and others for years so it has to be good enough :) Of
course it is probably not as good as commercial implementations
but I'm also wondering about Concierge's suitability and this is
why I initiated this discussion. I want to understand the
motivation, goals and expectations of the projects trying to use
concierge, and also because as a community, Eclipse we will have
to position the two implementations wrt to each others, as well as
evaluate and evolved the ecosystem around it (e.g. launching,
building, testing, etc.)
Pascal
On 23/04/2014 4:06 PM, Doug Schaefer wrote:
What do we mean by "optimised"? Couldn't we not go
through and do that optimization to address the size of Equinox?
Or are there big architectural differences that makes it harder
to do with Equinox?
(BTW, had the same question since I heard of Concierge).
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
|
