> I'm happy with the interfaces themselves. To all intents and purposes
> they hae been stable for years. Docs being incomplete is where I'll
> meet you on definition.
> True, but as third and fourth coarse containers enter the fray, they
> will seek to emulate first and second. Perhaps wrong, I accept.
This appears to reflect a fundamental disconnect that Peter, I and other
users seek to eliminate. It should never be the case that a justification
is given that "Well, container A doesn't work like container B therefore
..." This is not contract by prototype. I just want that point to be
crystal clear, all by itself.
-------------
So what to do about it? The semantic contracts need to be well-defined and
documented as part of the Framework. It is said that the only guarantee of
portability is through the Frameworks. We agree, and in wanting to enforce
that notion are pointing out that the Framework's semantic contracts need to
be more fully rendered. If there is a portable semantic, that contract
needs to be part of the Frameworks.
Specifically how that happens is certainly TBD. But is there any
disagreement with the basic goal?
> > As container/framework versions iterate, context
> > interfaces/contracts that are seen as generally
> > useful could be moved into the framework.
> Agree, but without the hierarchy (a fallacy).
Who was promoting it as a hierarchy?
> Only if you are interested in component/container interoperability.
> If you were a commercial company that had chosen one container over
> another, strongy typed context is an advantage.
This tension can be resolved.
As for the mechanisms, I agree that a mechanism should be simple (and
elegant). As for what is must be common, and what needn't be, I think the
current approach is that where there is client access, the interface needs
to come from Frameworks, but that doesn't mandate any particular
implementation.
By the way, I'm probably the person most willing to investigate an Avalon
Container model for James Mailets, and I am fairly sure that it will not
happen in the major redesign for James v3.0/Mailet API v2. For a number of
reasons: (1) we're still waiting to see what that would entail; (2) the
current instability within Avalon; (3) others (including Peter) are not in
favor of it, and I'm not likely to champion that approach given #2 with #1
still outstanding; (4) we have other design considerations to resolve. But
I will keep it in mind.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
