> 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...
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
