> > The type of data should be whatever is necessary to
> > define the context, whatever that means.
> I see your point, but I also think that there is some
> worth in having a narrow definition, as we otherwise
> risk having a massive Everything-Object.
No ... not a massive "everything-object." At worst, you'd be talking about
a massive composite name space. I don't think we get anywhere near that,
but I really do seem to have to stress the difference between Context as a
PROVIDER of services, and Context as a NAMING SERVICE.
I view Context as a naming service. The various profiles would mandate that
specific service providing objects shall be accessable through the Context.
For example, embedded containers would lack a process control service,
whereas application containers would provide one. And regardless of
implementation, when such a required service exists it shall conform to a
mandatory contract.
I am surprised that there appears to be an inclination to compose
interfaces, rather than keep components decoupled.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
