Peter,
1) Central definition of interfaces (and exceptions)
Pros : Simple solution Cons : Not version tolerant, though could have heretical version numbers in package or class names (ref LayoutManager2). Only good for regular server concepts (HTTPServer) as opposed to bespoke concepts (company X's ABC Server)
2) Promotion of interfaces (and exceptions). SAR file contains a jar of interfaces that it implements, it could hand it to the parent component (Phoenix) and Phoenix could make them available seperately, not necessarily at promordial level. It's an RMI type concept, but RMI is overkill for several reasons, not least of which is the ill-defined RemoteException.
Pros : Can tolerate different versions. Good for standards based services as well as bespoke ones. Cons : Difficult to implement
Thoughts?
I like (1)
OK, that's cool. Often simple is best.
Proposal : We move org.apache.avalon.cornerstone.services.* to org.apache.avalon.pheonix.services.*
This will pave the way for a central & default implementation of a particular service. Assemblers can still choose to have a particular impl bundled in their SAR file, but can (in the future) use a default block impl for the service.
As we introduce other blocks for really large server components, we can introduce services that express the features of those in a general way. I'm thinking multiple implementations of HTTP and EJB server all being interchangable given the same interfaces. As Peter says we should mark some of the interfaces as "in progress" in some way.
Regards,
- Paul H
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
