Hi all,
As Kai just said below: it is important to be
able to run Eclipse SmartHome on “any” OSGi framework, to
benefit from optimizations for restricted/embedded
environments.
I am just trying to run Eclipse SmartHome on
Concierge to see about dependencies. Until now it seems that
the OSGi framework is more or less fine (I raised some minor
bugs to Concierge, https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=concierge
). The question is more about the OSGi compendium services
on top.
As a sample I am trying to run Equinox DS and
EventAdmin on Concierge. This is NOT working actually as
Equinox-DS is referring to some internal Equinox Framework
impl classes, e.g. excerpt from Manifest:
org.eclipse.osgi.framework.log;version="1.0.0",
org.eclipse.osgi.service.debug;version="1.0",
org.eclipse.osgi.service.environment;version="1.2.0",
org.eclipse.osgi.util,
On the other hand it was very easy just to
install Apache Felix SCR from http://artfiles.org/apache.org//felix/org.apache.felix.scr-1.8.2.jar
into Concierge without any issues.
Regarding footprint of these services: Equinox
is definitely NOT bad, just comparing DS and EventAdmin as a
sample:
82934
org.eclipse.osgi.services_3.3.100.v20130513-1956.jar
(includes all compendium service classes)
106701
org.eclipse.equinox.common_3.6.200.v20130402-1505.jar
194441
org.eclipse.equinox.ds_1.4.101.v20130813-1853.jar
32690
org.eclipse.equinox.event_1.3.0.v20130327-1442.jar
77932
org.eclipse.equinox.util_1.0.500.v20130404-1337.jar
Compared to Apache Felix:
216530
org.apache.felix.eventadmin-1.3.2.jar (includes compendium
service classes for DS)
267629
org.apache.felix.scr-1.8.2.jar (includes compendium service
classes for EventAdmin)
I see these options for further work:
1. Equinox services will be refactored to run
on ANY OSGi framework, in first case on Concierge
2. Add (selected ?) OSGi service
implementations (e.g. DS) from Concierge project with goal
of small footprint (see IoT minutes at https://wiki.eclipse.org/IoT/M2MIWG/Weekly_call_minutes#Update_on_Concierge)
3. We may think about a small “compatibility”
framework extension to Concierge to provide the missing
services for Equinox services. This should definitely be
optional, to let Concierge as small as possible
4. We do not use Equinox services on Concierge
and use others (Apache Felix ?) instead
Any thoughts?
Bye, Jochen
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!).
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).
On Wed, Apr 23, 2014 at 2:23
PM, Thomas Eichstädt-Engelen <te@xxxxxxxxxxxxxx>
wrote:
Hi Pascal,
if “size” is equal to “resources” than this the
argument for Eclipse SmartHome for example.
Since Equinox is not really “optimised" for low
budget embedded devices (like Raspberry Pi)
Concierge seems to be a promising approach.
Best, Thomas E.-E.
_______________________________________________
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