ServiceManager/Serviceable -> Director/Actor?

[Antti Koivunen <an...@users.sourceforge.net>]

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.

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 :)

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.

The new classnames could be:

   org.apache.avalon.framework.role.Director
   org.apache.avalon.framework.role.DefaultDirector
   org.apache.avalon.framework.role.Actor
   org.apache.avalon.framework.role.ActorException

These remind me of the practical names I've used in AOP (e.g. Group, 
Member), but some people might prefer technical terms. The idea could be 
extended with terms like agent, audition and studio (though not sure for 
what purpose).

So, is this way too silly or actually something to consider?

(Stabilizing ServiceManager is of course the first priority. The final 
name of the interface is a separate issue.)

(: A ;)



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ServiceManager/Serviceable -> Director/Actor?

[Antti Koivunen <an...@users.sourceforge.net>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ServiceManager/Serviceable -> Director/Actor?

[Berin Loritsch <bl...@apache.org>]

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.



> 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.



> 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.

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.

You can even have the psuedo-protocol be the ROLE of the object you
want. I.e. when you want a Transformer, you would do this:

resolver.resolve( Transformer.ROLE ); // gets the default transformer.
resolver.resolve( Transformer.ROLE + ":foo" ) // gets the "foo" transformer.

And yes, Cocoon's sitemap uses the concept of default components!

> 
> The new classnames could be:
> 
>   org.apache.avalon.framework.role.Director
>   org.apache.avalon.framework.role.DefaultDirector
>   org.apache.avalon.framework.role.Actor
>   org.apache.avalon.framework.role.ActorException
> 
> These remind me of the practical names I've used in AOP (e.g. Group, 
> Member), but some people might prefer technical terms. The idea could be 
> extended with terms like agent, audition and studio (though not sure for 
> what purpose).
> 
> So, is this way too silly or actually something to consider?

I think it is a step backwards.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>