iPOJO inspiration (Was: Re: ServiceTracker)

["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