Peter Kriens wrote:
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.
In Felix, no subsystems use it, but if we decide to keep it in there,
then they might, since I do something similar in URL Handlers.
When I write the inspiration for iPOJO I used the ST for the low
level dependency management for this reason.
Well, I don't know if I would state it that way...the inspiration of
iPOJO actually revolves around an idea I had for how to do composite
services using byte code generation.
The discussions that you and I had around byte code manipulation as an
approach for doing DS during the months leading up to the R4 spec were
the inspiration for creating Service Binder++, which is the core of iPOJO.
After that, Clement's inspiration has taken iPOJO aflight... :-)
-> richard
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.
