> As to the question of DS, let's not forget that
it is just an
> instrument. From what I understand, its goal is to help developers
> work around OSGi complexities. If it does not help, it needs to be
I am all for fixing DS if it is flawed. But your argument
against using startlevel can be applied to anything which attempts to fix
some ordering. The difficult point is that bundles can be interdependent.
They and services are dynamic. You can attempt to hide the dynamism through
the use of static policies in DS but that only goes so far. Using DS, one
can fairly easily deal with service dynamism. There are bind/unbind methods
which are called when services come and go so the bundle can be notified
of changes to the set of services.
I feel that changing DS to perform service registration
synchronous with bundle activation will likely result in deadlocks when
there are complex service dependency graphs.
One possible way to deal with this is through the
use of component enablement. Using the original example of service A depending
upon some number of service B, if you can know when all the service Bs
are available, one can write a component with a dynamic dependency on B.
When all the Bs are available then enable the component providing service
A (which are declared disabled in its description). The trick is of course
to be able to know when all the service Bs are available such that we are
ready to enable serviceA.