[Zope3-dev] More name game suggestions

[Shane Hathaway]

Florent Guillaume wrote:

> By the way would CMF Tools be akin to services or utilities ? Or it
> depends ? :)
> 
> I'd see most of them as services, but would like to be sure...

That's right.  portal_catalog, portal_types, portal_skins, 
portal_metadata, etc. will all be services (though some may be replaced 
by Zope services.)  But portal_url and portal_undo should be utilities 
since they don't store any data or provide a new kind of component registry.

It's a little early to tell, but in fact I think most services are 
component registries.  A utility is *not* a component registry.  If you 
need not just a new component but a whole new kind of components, you 
define a service then start registering components in it.  Once we have 
a few services, though, most people won't have any need to create new 
services.  Most people will create components designed to be registered 
in a service.

Frameworks and toolkits are very different things.  One framework in 
Python, for example, is asyncore.  You can't just add asyncore support 
to your app; your app has to be designed around it.  Most of Python, 
however, is more like a toolkit.  You can just add a call to base64 to 
support basic HTTP authentication.

So you see, toolkits are usually much easier to use than frameworks. 
But because of limitations in (continuation-less) Python, there is no 
way asyncore could be written as a tool without limiting its capabilities.

Creating a service is adding to the Zope framework, while creating a 
utility (or any other kind of component meant to be put in a service) is 
adding to the toolkit.

Now, I remember someone asked why components can't all be put in the 
same registry.  I'm afraid this wouldn't make any sense.  Services are 
just registered by name, so they fit in a simple registry.  But 
utilities are registered by interface.  If you ask for a utility that 
supports a superinterface of a registered utility, the service should 
return that utility unless another registered utility supercedes it.

That's doable in a relatively simple registry, but now consider 
adapters.  They are registered by *two* interfaces.  The service has to 
look for any registered adapter that supports a subinterface of the 
requested output interface and a superinterface of the provided input 
interface.  That's nonsense in a simple registry! :-)

If that didn't convince you that there are many kinds of registries, 
this will: a view component is registered by two interfaces and a name. 
  We're considering changing them to be registered by two interfaces and 
two names, with the second name representing stackable view layers.

Maybe we could say utilities and services are the same thing.  That 
would mean you'd need to be able to register components in utilities. 
Then we'd eventually realize that being a component registry requires a 
heavy contract and most utilities don't need to be component registries. 
  We'd then decide to divide utilities into "simple utilities" and 
"component registry utilities".  Then we'd figure out that a few other 
utilities want to be central like component registry utilities, and we'd 
turn them into component registry utilities just to make them central. 
"Service" didn't really go away, did it?  It therefore must exist.  ;-)

Shane