You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2007/05/22 20:08:45 UTC
Re[2]: ServiceTracker
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
iPOJO inspiration (Was: Re: ServiceTracker)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Clement Escoffier wrote:
> Richard S. Hall a écrit :
>> Peter Kriens wrote:
>>> 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... :-)
> iPOJO's roots are multiple. Several inputs and objectives was mixed
> before reaching the actual iPOJO. First of all, there was Rick and the
> idea to extend Service Binder (SCR) to obtain a simplest development
> model and to create composite services. It was (and it is) always the
> main goal. It wanted to use bytecode manipulation to create this
> composite service on the fly. However, Peter and his SCM (I cannot
> remember the exact name) was a great starting point. The bytecode
> injection was used to manage service dependencies. Moreover, a
> discussion we had with Peter at Las Vegas (in January 2005) was also
> an important actor. However, my old projects around OSGi.NET, the
> Fractal Component Model, Aspect Oriented Programming, also had an
> undeniable influence (Moreover all these projects were directed by
> Didier Donsez).
>
> It seems that iPOJO is a kind of large mixture of heterogeneous
> ingredients. It was an experimental recipe ;-)
Yep, there are definitely many inspirations...
The only point that I tried [inadequately] to make was that the raison
d'être of iPOJO (and thus Clement's PhD thesis) was to explore how to do
dynamic composite services in an environment like the OSGi framework.
It was just a bonus that discussions with Peter and his ideas behind
"removing cruft" also found their way into the core of iPOJO's service
dependency management mechanisms.
Thanks, Clement, for setting the record straight. :-)
-> richard
Re: ServiceTracker
Posted by Clement Escoffier <cl...@gmail.com>.
Richard S. Hall a écrit :
> Peter Kriens wrote:
>
>
>> 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... :-)
iPOJO's roots are multiple. Several inputs and objectives was mixed
before reaching the actual iPOJO. First of all, there was Rick and the
idea to extend Service Binder (SCR) to obtain a simplest development
model and to create composite services. It was (and it is) always the
main goal. It wanted to use bytecode manipulation to create this
composite service on the fly. However, Peter and his SCM (I cannot
remember the exact name) was a great starting point. The bytecode
injection was used to manage service dependencies. Moreover, a
discussion we had with Peter at Las Vegas (in January 2005) was also an
important actor. However, my old projects around OSGi.NET, the Fractal
Component Model, Aspect Oriented Programming, also had an undeniable
influence (Moreover all these projects were directed by Didier Donsez).
It seems that iPOJO is a kind of large mixture of heterogeneous
ingredients. It was an experimental recipe ;-)
Clement
PS : About the Service Traker, iPOJO does not use it to avoid this
dependency, and I am a service listener fan. If the performance are
really improved, why not use it. So, +1 to insert the service tracker
inside the core.
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: ServiceTracker
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
>
>
>
>
>