On 5 jun 2008, at 16:55, Niclas Hedhman wrote:
Scenario; 600 bundles, all use Log Service, Log Service
implementation needs
an upgrade. 600 bundles stopped, 20 minute startup time (we got
terrible
bundle developers ;o) , instead of a sub-second reload of the
LogService Impl
bundle ( well, and a few thousand ServiceTrackers working
overtime ;o) )
With these things there is only one answer: show me. Try to create a
real system
that shows this behavior and where updating this "used by all" bundle
becomes
a real bottleneck. It is easy to dream up horror scenarios but in
reality you do
not update the log service bundle many times a day, if ever. I suspect
the
more a bundle is used, the less frequent its updates are because it
needs to be
stable. But I would have to measure that to know that with more
certainty.
If the version of the LogService is updated, you're still screwed :-(
Anyway, if you have bad bundle developers, who cares? Then you have
lots of other
problems as well, then this seems to be the least of your worries. :-)
IMHO, the lower down the application stack you are, the greater the
benefit to
separate API from Impl. And for large applications, it doesn't
matter if I
need 200 or 400 bundles for it to run, I still need a good Bundle
Management
system in place.
Yeah, lets make a big mess so we can sell tools to solve the
mess ... :-) This
is a multiplier effect I think we allow too often. Though I do agree
with
a good bundle management system, I do not think that should become an
excuse
to multiply the number of bundles.
Anyway, the trick is, as several people have said, to understand your
use case
and make your own trade offs. Just want to make sure that this is not
a black and white world and there are trade offs.
Kind regards,
Peter Kriens
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
