[Zope3-dev] More name game suggestions

[Phillip J. Eby]

At 12:50 AM 12/9/01 -0500, Shane Hathaway wrote:
>- Services are like the ground you stand on.  You can just assume they are 
>there.  Utilities are like your wristwatch.  You forget to put it on sometimes.
>
>- You can register components with a service.  You can not register 
>components with a utility.
>
>- Services can implement complex kinds of component registration, while 
>utilities are always registered in a simple way (that is, just the output 
>interface or a name).  For instance, presentation services allow you to 
>register components by the combination of input interface, output 
>interface, name, and layer.
>
>- Services are rarely application specific.  Utilities are often 
>application specific.  You should create an XML parser as a utility, not a 
>service.
>
>- There will be a lot of utilities and relatively few services.
>
>- In most cases, new developers want to create utilities, not services.
>
>- Most of the time, services don't do any real work.  They usually just 
>find a component or call a component.  Utilities usually do work.
>
>I think "utility" is a very fitting term.  "Application component" is too 
>general.


Wow, this all sounds pretty confusing to me.  Is a database connection a 
service or a utility?  If you'd asked me before this e-mail, I'd have been 
certain it was a service.  Now I haven't a clue.

Honestly, from what you've described, it sounds to me like the names are 
backwards, because to me a Service would be something you'd want to have a 
lot of, with relatively few Utilities (based on the names alone).  Also, if 
the purpose of a Service is to register components, then why isn't it 
called a Component Registry?  I'd think that a service was any component 
that could be looked up "placefully" by name or interface, and a Component 
Registry would be a specific kind of service dedicated to registering other 
components.

Personally, I think having such a narrow definition of "service" is going 
to be a bad idea, from a marketing perspective if nothing else.  What about 
"web services"?  You're basically saying "we want relatively few services", 
which sounds really bad in a marketing context.  :)  Now, if you say, "we 
want relatively few component registries to avoid confusion of where to 
look things up, but you can have all the other kinds of services you want," 
that sounds much better.  :)  Utility, meanwhile, just doesn't sound like 
it belongs at all.

Take it from the author of the infamous ZPatterns...  awkward terminology 
can really hinder the adoption of a technology.  :)