[Zope3-dev] More name game suggestions
Shane Hathaway
shane@zope.com
Fri, 14 Dec 2001 14:19:00 -0500
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