> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of
> the real...
I think that one of the differences is when you start using a
token to free resources, which does not make sense for a Service,
assuming that a service is Thread Safe and you just get to use it.
So, if for services you would always have (although I still do
not like these keys):
interface ServiceManager
{
Object lookup( String role );
Object lookup( String role, Parameters attributes );
void release( Object component );
}
for a ComponentManager you could have:
interface ComponentManager
{
Object lookup( Object token, String role );
Object lookup( Object token, String role, Parameters attributes );
void release( Object component );
void releaseAll( Object token );
}
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 13, 2002 5:17 PM
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > Berin:
> >
> > Paul's vote on the ComponentManager interface proposal brings
> > the number of +1 votes to 3, sufficient to go ahead with the
> > ServiceManager proposal. Your reply on the initial request for
> > vote was somewhat unclear with respect your position. If I
> > understand correctly, you stated that in principal you would
> > be -1 on anything not linked to Avalon 5.0. As the proposal
> > is not linked to Avalon 5.0, can you clarify for me if your
> > message should be counted as a veto. If not, I'll go ahead
> > a commit the proposed service package this afternoon.
> >
> > Cheers, Steve.
>
>
> :/
>
> I thought you could tell due to the fact that I was presenting the
> Resolver package as an alternative that I haven't moved to +1 yet.
>
> I want to eventually add in a Query object ability--so we have two
> options.
>
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
>
> 2) The ServiceManager has two methods: one String, and one Query object
>
>
> Due to all the feedback, the Query object would be simplified to one
> key and attributes.
>
> Another alternative to the whole explicit Query object is the following:
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
>
> This way, we can reasonably handle default Lookup, and have no need for
> the ComponentSelector equivalent.
>
> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of the real
> world, we need to address a specific configuration of a Component. The
> ComponentSelector was introduced to satisfy that goal. However it is
> terribly clumsy to have to do two levels of lookup.
>
> Please post your thoughts.
>
> If we introduce this change, we won't be able to add the extra
> functionality
> later for the Query object.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
