Stephen,
> Be warned - it's one of my longer emails.
We'll get you the book on Agile emails on day ;-)
> [ A-F interfaces, interfaces only or interfaces + meta ]
> What is does do is define the interfaces and artifacts used in the
> interaction of a container with a component. ....
For me that is fine. A-F is used in EOB, commercial componentization projects,
internals of other
open-source projects.
There is a case for saying that some of the inteface definitions for Phoenix's
BlockContext need
to be abstracted to somewhere else if Merlin is unwilling to import and provide
phoenix-client-api.jar. See Later*
Merlin and Phoenix do not represent the only containers that will ever be written. It
is a
fallacy to tie one component-lacing scheme to the A-F project.
> >> In another thread, Paul Hammant and Peter Goldstein were discussing
> >> issues
> >> over how to add more robust semantic contracts to the Frameworks.
> >> More work
> >> to do, but acceptable points of convergence appeared to be in the
> >> offering.
> >
> >
> > I'm pretty sure that everybody on this list is tired of fighting and
> > cares about Avalon enough to set aside personal issues and work toward
> > a common goal.
* Right. In my email excange on that issue that Peter Goldstein was also involved
with, I was
trying to come up with positive suggestions for past and future issue of BlockContext
(and alike).
As part of my discussion I took time to see the other person's point of view and
modify my
position, trying to propose multiple things that might be acceptable. Unfortunately
that came
across (and was stated as such) as arguing against myself.
My votable position is summarisable to :
1) No change to Context.class for specific containers.
2) No GenericBlockContext type (interface/impl merging) changes to Phoenix
3) No massive hierarchies of sub-interfaces to Context.class
Currently I feel these are some very small facets of context expressable in individual
interfaces
and in A-F-API. One example is :
interface ShutdownRequestingContext extends Context {
void requestShutdown();
}
Now, it is up to the container in question as to whether they will implement that, and
also to an
extent how they implement that. Phoenix and Merlin would undoubtedly implement it.
EOB would
not.
Phoenix might change BlockContext to extend that interface (for back-compat), but
otherwise
deprecate BlockContext. JAMES might not implement it (PeterG - forgive Avalon people
for
imagining /their/ ideal world Mailet engine).
A client side usage might be :
contectualize(Context context) {
ShutdownRequestingContext src =
(ShutdownRequestingContext) context;
src.requestShutdown();
}
With this design, it would be compatible many containers.
Where the line is drawn, is for specialized containers's specialzed context features :
interface MailForwardingContext extends Context {
void forwardMail(MailItem item, String recipient);
}
In that case, the interface stays in JAMES CVS not in A-F-API.
Stephen - please meet me in the middle here, this is a significant modification for
me, as you
know it is not a loss to move you position :-)
Imagine the diseased possibilities - a future uberubercontainer could be a mailet,
servlet, bean,
any component hosting server - out of the box. Hmmm ;)
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
