One of the design goals of the ServiceTracker was that it could be
optimized by framework vendors. If you look at the implementation, you
will see that there are some inefficiencies in the implementation
because it must use the standard listeners (it must listen to all
service events when you use it with a listener). Making the ST highly
efficient on your framework would allow other subsystems to reuse
this. When I write the inspiration for iPOJO I used the ST for the low
level dependency management for this reason.
Kind regards,
Peter Kriens
MO> On May 22, 2007, at 18:07 , Richard S. Hall wrote:
>> Since the overall response has been positive (even though I am
>> mostly in the "excess cruft" camp with Eric), I have gone ahead and
>> added it.
MO> I'm also in that camp, but I was at a conference (without internet)
MO> today, so I missed out on the initial discussion.
MO> I'm wondering, if ServiceTracker was supposed to be part of the
MO> framework, why didn't OSGi define it as such. Since it's not part of
MO> the framework, I don't like including it in Felix by default. It just
MO> increases the size of the core.
MO> So in my opinion we should not include it by default.
>> Of course, BND could solve this by having people just pull ST into
>> their bundle. But if everyone were to do this, then the savings we
>> see by not having ST in the framework JAR would be quickly
>> outweighed by the multiple copies of ST embedded into all of the
>> bundles that use it.
MO> If people don't need the whole compendium, they are free to create a
MO> meaningful subset of it and use that. That's the other option they have.
MO> If people are using another dependency manager (such as iPOJO) then
MO> they don't need to use ST and you might actually want to discourage
MO> people from using it at all by not providing it.
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
