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]
