Leo Sutic wrote:
>
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>
>>>As for what the Serviceable interface is: I always considered it
>>>nothing more than a
>>>method for Avalon component to access non-Avalon components
>>>
>>via a unified
>>
>>>lookup mechanism.
>>>
>>
>>Nothing less!
>>
>
>OK, so it's, like, x = what I said, y = what it really is,
>lim[E -> 0] ( x - E < y < x + E ), dude? There, set in stone.
>
>
>>>Random thought: With the Proxy generator Berin put in the
>>>
>>ECM, doesn't
>>
>>>the whole
>>>need for Serviceable disappear?
>>>
>>
>>Urggh #&$
>>That's a hack - the approach you outlined above is the right one -
>>recognition of the implications of version and respectin this
>>in terms
>>of the components that have been released, combined with rigerouse
>>documentation of future component releases.
>>
>
>The solution I outlined is also the solution that has the most
>dependencies on:
>
> + People changing their code.
>
> + Us keeping our documentation up to date.
>
> + Us ensuring that 4.0-specific components don't require 4.1,
> due to developer mistakes.
>
>In other words, probably our three weakest points.
>
>The Hack would be a "hack" from the container POV, but would
>eliminate the 4.0/4.1 difference. Of course, the hack only
>works if everything looked up via the CM interface can be
>proxied (that is, it must have a role interface that we can
>use to create a proxy). So you can't lookup an ORB, because
>it is an abstract class, and not an interface. You can code
>around this by defining an ORB interface, but...
>
That's not the case - things like an ORB, transaction server, persistent
state service (PSS), naming service are all example of concrete classes
that represent services in accordance with a standard - the list goes on
and on - coding around these services means that your creating and
exposing non-standard services. The notion that a service provided by
or consumed by a component must implement a interface defined in Avalon
was wrong, is wrong and remains wrong - but that's part of the healthy
process of framework evolution.
Compliance is something rather novel in the Avalon world as and I think
we would have a very difficult time typing to establish a compliance
criteria for 4.1 or 4.0 any time soon. The reason is that the framework
interfaces have some semantic holes - things like the interpritation of
the value passed in the lookup operation (as the most glarring example).
An Avalon Framework 4.2 could attempt to clear these issues up.
Steve.
>
>/LS
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
