[Zope3-dev] More name game suggestions

[Martijn Faassen]

Phillip J. Eby wrote:
[snip]
> Wow, this all sounds pretty confusing to me.

Let's all agree the naming could use improvement; several of us got
confused. :)

This is what the wiki says about them:

> Utility Components

> Utility components are components that serve only one specific function,
> and are not designed to act on another component. A good analogy for Python 
> programmers are functions and methods. Utility components, like Python
> functions, are standalone objects that do not need any other objects to do
> their work.

This doesn't work for me; Python functions do use other objects to do
their work, i.e. the ones passed along to them. And will these utilities
be unconfigurable? I mean, if they are allowed to access information
about the place they're in or where they're invoked, then they're more
like methods than like functions. 

> Feature components, like Python methods, require another object
> to work upon.

Adapters adapt another object. Hm, how much better that word is, it's so
instantly clear that they do require another object. :) (though I wouldn't
say they 'work on' another object..'work for' is perhaps a better description
of what they do.

> Utility components will mostly be used for simple, throw-away components
> that serve one simple task, like an XML parser.

Aside from the fact that here we're calling an XML parser a 'simple throw-away
component that serves one simple task' :), I could see an XML parser being
a global service easily. In fact that's how Zope3 is using one
currently to parse its config files, right? What if I wanted some
parsing features (say there's somekind of include directive or we need
to access a DTD or schema) dependent on the location the parser is in?

> Service Components

> The last kind of component is a Service Component. Services are a small
> set of core functionality provided by the Zope platform. These can be
> thought of as the "kernel" that Zope provides for your web applications.
> Services we anticipate existing in Zope include user sessions,
> authentication, workflow, content-type management, and even managing
> your components themselves.

But these are also placeful and can be replaced with others, right? 

Should we be making the distinction between 'services' and 'utilities' at
all? Isn't a utility some sort of simple degenerate service?

Perhaps we should be speaking of 'global versus local' services or something
like that. It's possible for something starting out in development as a
local service for one or a few applications to evolve into something more
powerful and end up as a global service.

Finally a question on services and place. Let's say we have a workflow
service in Zope. What does this mean in effect? In one view, I'd say we 
ask for the global workflow service object, call some methods on it, and do
our stuff. But my workflow may be configured locally, so how does this
work? Does the service keep a repository of workflows, or what's going on
here? 

The other perspective says the workflow service is configured with a bunch 
of objects I create in the place I need to use that workflow. The 'service' 
is really nothing more than the objects I now can access and the methods
their interfaces say should be there. There is no central repository of
workflows (unless these local components specifically provide for such
a thing, perhaps through a catalog).

I can see the same story for the 'form' service. Say there's a Formulatorish
thing in Zope, and it offers services where you can define and validate
forms. But in essence what you do is just create a Formulator form in
the folder where you want to use it, and the form object offers all the
definition and validation services you need.

I rather like the local model; it's nice and lego-brickish. That's not to
say global or shared repositories and indexes can't be useful, but a local model
allows one to develop applications more independently from each other,
which seems more flexible.

Anyway, I'd prefer it if Zope 3 dealt with everything as local, and that
global falls out from that -- if you want something global you simply 
define it in the 'root'. This is how acquisition is commonly used in Zope 2
and it's a good feature, except that it doesn't offer enough ways to 
structure and make things explicit (which is the reason Transparent Folders are 
popular with some, it helps there).

Regards,

Martijn