[Zope3-dev] More name game suggestions

[Guido van Rossum]

> >  http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SecurityFramework
> 
> Wrong page? Can't find anything on utility on this page.. 

No, but it has several mentions of services, e.g. (this is repeated
three times, suggesting either that it's really important, or
copy-paste mania :-):

"Because they implement services, they are expected to collaborate
with services in other contexts. Client code doesn't sarch a context
and call multiple services. Instead, client code will call the most
specific service in a place and rely on the service to delegate to
other services as necessary."

> > When you use a "service", there is this notion that you vaguely ask
> > for one and the one nearest to you gets the request; that one will
> > communicate with others of the same kind higher up in the hierarchy
> > and eventually give you a result.  (Similar to methods and method
> > overloading.)
> > 
> > When you use a "utility" you pick one you like and that's the one you
> > get.  (Similar to a function, I guess.)
> 
> Yes, I got a similar impression, but apparently either Ken typoed or has
> a different idea (or I read him wrong). From his new cheatsheet:

(Which is unfortunately way too abstract for me to understand what
it's trying to say -- maybe it helps if you know Zope 2 inside out
though.)

> > Service component type
> 
> > Core tools whose functionality is used by many different types of
> > components - correspond to CMF "tools". Service manager is the most
> > fundamental - the "big flat lego sheet, on which the rest of the legos
> > are placed".

Can we please drop the lego references?  The don't help! :-(

> > Contrast with Utility - name of Service is crucial, can have multiple
> > services that implement same interface in the same place, distinguished 
> > by name.
> 
> > Utility component type
> 
> > Like Services, Utilities are independent resources, but aren't
> > foundational - they're generally specific to an application or
> > application domain. For Services, the interface is the crucial aspect
> > - can not have utilities that serve the same interface (purpose) in the
> > same place.
> 
> I'm confused. Isn't it exactly the other way around in that there can be
> multiple utilities in one place with the same interface, distinguished by
> name? With services I have the concept of 'gimme the nearest authentication
> service' or 'gimme the ZDOM service that applies here' (sorry Jim, still
> don't see how a DOM is part of a presentation or view component..) or
> whatnot. That seems like there can be only a single services in a place
> for a certain interface..

I'm guessing here that a utility is a one-off thing, while a service
is something that's carefully designed into the infrastructure to
allow multiple implementations.  Ken's words match with that
interpretation.

Kind of like the way "mapping", "sequence" and "file-like object" are
generic interfaces in Python, and could be considered somewhat like
Zope services.  While other things (e.g. frame objects, mmap objects,
curses screen objects etc.) are one-off types/classes, similar to Zope
utilities.

Except that the Zope services also have a common name that you can
toss up in the air and the nearest service says "yoo hoo! here I am!".

> Though taking the XML parser example, utilities seem to be global in
> some sense as well. But then I think in terms of 'give me the XML parser'..
> But isn't that much like a service? It seems like a global service type
> thing, while utilities are supposed to be application specific. To me
> that implies local. (though application domain specific, such as XML,
> could indeed be global) 

I guess the point is that an XML parser doesn't implement a local
policy that overrides and extends a more global policy -- it's just a
piece of code with a name.  (Maybe it's just confusing to mention that
the Python xml package in fact has a way to ask for an XML parser that
looks in serveral places to find one -- this is more like Zope
services.)

I would love to see examples -- it seems that my brain can generalize
very quickly from even a lousy example (yes, even from an
intentionally bad example), while it has an extraordinary tough time
figuring out the meaning of or examples for something that is
specified in the abstract sense.  Some of the key Zope folks seem to
have the opposite wiring of their brain... :-( / :-)

To present an example of something that *I* think of as a typical Zope
service: a user authentication service.  There's a global one
(probably based on a user folder in the root, though that's a
configurable site policy), but there could be a local one that takes
e.g. a particular LDAP database into account.  To use this service,
you don't specifically ask for the latter -- you just ask (in a
placeful way) for "the prevailing user authentication service" and
that will get you the most local one; if you ask it a question it
can't answer, *it* will pass the question on to the next one up and
return whatever answer that one reports -- and so on recursively,
except that the last one in the chain will throw an exception if it
has no answer.

> I'm still not convinced this difference is a qualitative one, or that the
> line is drawn in the right place. But even if I'm wrong, what we need
> now is a set of good examples of both utilities and services and
> reasons for each one explaining why it's a service, or a utility, and why
> not something else again, like an adapter.

Exactly why I am begging for examples.

> The fact that Phillip Eby is confused shows enough! :)

I don't know Phillip or his reputation, so I don't get the joke if
there is one.

> Could we fit the word 'module' into all of this somehow? It would strike
> me as if many utilities are basically Python modules plugged into Zope
> somehow (or created inside Zope), is that correct?

And then services would be what?

--Guido van Rossum (home page: http://www.python.org/~guido/)