Hi Kai,
I agree that the difference with the NodeJS based apps is
annoying. Unfortunately I think that a main difference lies in the
way the VMs operate (e.g. a JavaVM interpret and eventually JIT,
whereas V8 immediately generate machine code; also JVMs have to
verify bytecode and probably do a lot more work). However this is
not a reason to ignore the overhead caused by the framework, and I
invite you to take this discussion to the equinox-dev ML where
Tom, BJ and others will be able to provide more specific insight.
The other thing that you may want to look into is adopt the
new java 8 compact profile. For the longest time, Equinox, p2 and
other fundamental components use to compile against smaller
environments (e.g. Java 1.4, Foundation, CDC, etc.) but because of
a lack of interest and overhead it caused the dev team, this was
abandoned (though not for Equinox) and numerous projects just
started using 1.5 or 1.6 as their BREE. However now that the
compact profiles are better structured (each being a super set of
the next one), then I think making some of the bundles you need
depend on those should not be too much work.
HTH
Pascal
On 24/04/2014 4:04 AM, Kai Kreuzer wrote:
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
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
|