Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3C71E7AB.5070208@users.sf.net>
Date: Tue, 19 Feb 2002 07:50:35 +0200
From: Antti Koivunen <anryoshi@users.sourceforge.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: ServiceManager/Serviceable -> Director/Actor?
References: <3C6E8FC0.2010706@users.sf.net> <3C7105A5.5000005@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Berin Loritsch wrote:
> Antti Koivunen wrote:
> 
>> Hi there,
>>
>> When I first stumbled into Cocoon 1 a few years back, I remember 
>> really liking the intuitive names of the core interfaces, Director and 
>> Actor. Given the confusion surrounding Component/ServiceManager, and 
>> the somewhat valid argument that Object != Component != Service, I 
>> think this might be something to consider.
> 
> 
> This was Avalon version 1.  It was never a released project, just used
> as the basis of some other projects--and avalon continued to evolve.

OK, I've just been around since version 3.

>> The main purpose of Component/ServiceManager is to look up an object 
>> that matches the specified role (behavioral interface), so the idea 
>> would go well together with the Director-Actor naming scheme. Having 
>> intuitive and 'fun' names for the core interfaces could also make the 
>> framework more approachable (Composable???). Programming is serious 
>> enough as it is :)
> 
> 
> It has the same problem... Director returns something that implements
> Actor.  We do need something that returns an Object.

I would *never* allow Director to return anything but an Object. I just 
thought the term Actor well describes an object that cannot operate on 
its own (no offence to any actors :), but can work wonders when part of 
a play (given a Director).

>> Personally I don't have any problems with the name ServiceManager. 
>> "Providing the service specified by the role" makes perfect sense to 
>> me, and I also like the term Serviceable. But as these are the names 
>> we'll be looking at for a long time, I thought everybody might want to 
>> have a say.
> 
> 
> I have one issue--A service is more narrow than a Component, and the
> return type is more broad.  Therefore, ServiceManager is not a good
> name.  Resolver is a good name because it can "resolve" objects of
> any type.

I have no problems with "Resolver", either.

> The psuedo-protocol approach allows the simplification and narrowing
> of what you expect.  I.e.: when you look up a Component you want a
> component.  When you look up a file, you want a file.  The Resolver
> would be able to communicate with the Container and have that resolve
> all the references.  It works well.

Role based lookups are semantically different from e.g. file lookups, 
i.e. you want to get anything that matches the specified role 
(behavioral interface). In other words, having:

   "component://com.domain.Thing"
   "service://com.domain.Thing"

mixes concerns, but the following would be fine:

   "role://com.domain.Thing"
   "file:///home/thing/file.xml"

If the concern of role based lookups was separated into a single 
interface, the name Director would work well, but for pseudo-protocol 
lookups, Resolver is of course much better.

(: A ;)


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>