Toni,
Sorry but you were misinformed. Check out the package
org.eclipse.core.runtime.dynamichelpers, and the class
ExtensionTracker etc. Extensions certainly can be installed an
uninstalled dynamically.
A reason for this misconception is that, prior to Eclipse 3.0, the
low level runtime was non-OSGi based and could not handle dynamic
installation and uninstallation of bundles. The OSGi Service Layer
would also be non-dynamic if it didn't have the Module Layer and
Lifecycle Layer beneath it.
I would really like to discuss the specific concern of scalability,
rather than extensions vs services in general terms.
Regards,
Neil
On 30 Apr 2007, at 11:35, Toni Menzel wrote:
The last thing I heard from "Eclipse Extension Registry" is that it
does not provide dynamic bindung/unbinding at all.
It greatly benefits from caching bindings initially found but
"polls" the resources as needed (lazy resource provisioning).
But when it comes to really attach/detach OSGI Services the whole
registry needs a rebuild ("rebuild" might be wrong.. but at least
it is what is force for example when starting eclipse with -clean
option)
This lack of dynamic behaviour makes this registry not comparable
to osgi services in my opinion. (i've heard that this is a concept
from pre-osgi times at eclipse 2.x)
if someone has more experience with this extension registry, please
clarify. I would like to know more about it, too ;-)
regards,
Toni
Neil Bartlett schrieb:
All,
A criticism that I have heard about the OSGi Service Layer,
particularly in discussions where it is compared with the Eclipse
Extension Registry, is that services "do not scale".
I would like to pin down exactly what is meant by this, and try to
quantify:
a) How bad the problem is, if it exists
b) Whether the problem can be fixed by an implementation, or
is intrinsic to the design
c) Whether and how the Eclipse Extension Registry achieves
better scalability.
The problem I have is that "scalability" can mean so many things.
For example it might mean that service registry lookup time
becomes unfeasible when the total number of services becomes very
large. It's difficult to see how a single lookup could be worse
than linear, so presumably the problem here is when lookups must
be done repeatedly -- and if this is the case, would some form of
caching or indexing help? Alternatively the problem might the
dynamic "churn" that the Spring-OSGi guys are so concerned about,
i.e. when dependent services are added and removed so quickly that
a significant amount of time is spent merely reacting to
ServiceListener events rather than doing useful work. But surely
the same problem would affect extensions?
It seems to me that one potential difference is scoping. In
Eclipse, an extension point defines a search scope, and the
definer of the extension point tends scans the registry for
extensions contributed to that particular point. This means an O
(n) operation, with n being the number of extensions contributed
to the extension point.
With OSGi services, one can simulate a scope simply by adding a
registration property to the service. If the service registry knew
that this property was being used for scoping, then it could
create an index for it. However, the registry does not have such
knowledge, so in theory it needs to perform an O(n) search where n
is the size of the entire registry. However this is only a guess;
I haven't examined the source code or performed any benchmarks.
Would anybody like to comment on whether and why they think that
OSGi services either do or do not scale?
Thanks,
Neil
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
