[Zope3-dev] More name game suggestions

[Martijn Faassen]

Guido van Rossum wrote:
[snip]
> "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."

Okay, doesn't seem to conflict with my idea of what 'service' means
here..

[snip]
> > 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.)

Most of these concepts are newly introduced, and it's hard for quite
a few folks apparently, if you actually start to think it through. I mean,
reading these things for the first couple of times I generally thought 'um,
yeah, makes sense', but then when I actually started to think in code and
user interface and so on, wondering what these things look and feel like,
and how you'd use them, suddenly it becomes a lot less clear. 

> > > 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! :-(

I think pushing it beyond 'you build an application out of lego bricks'
strains the metaphore beyond endurance. :)

The service manager is the kernel service.

[snip]
> 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.

Yes, I think everybody has more or less agreed on this. Rereading Ken's
stuff with your reiteration of utility being a one-off things makes it
more clear.

Utilities are things that are for a particular application. Their interface
is created 'on the fly', or at least is dedicated to your application or
application domain. It makes less sense to distinguish between interface
and implementation here. You just refer to the utility by its name and get 
it. You don't look up utilities in any complicated fashion, you just know
that they're there and get the ones you need.

Services are for more general usages. Their interface is designed and used
separately. You don't look services up by name, you look them up by
interface, and the application doesn't care what service it'll get as long
as it conforms to the right interface.

If this distinction is correct, we *definitely* need a very smooth path
to turn a utility into a service. As in practice, we cannot design interfaces
separate from actual use. We often abstract away when we see commonalities
appear during the actual writing of application(s), not before that.
In component lingo, this means we evolve a utility into a service by
explicitizing and standardizing on an interface for a group of utilities
that turn out to be related, and registering these utilities with a service
registry together with the interface. And there we have a new service.

This also means that there are services only used within a particular
application domain or even application.

> 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!".

Yes, I think this makes sense. I think we can either come up with
better words or with much better descriptions of services versus utilities
now that we know what it is really about (if I'm correct :) -- it's about
whether you deposit your interface is separate from the implementation or
not (and whether you deposit your interface with a central manager).

> > 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.

Though people want to implement local policies for the strangest things.
That's one of the nice things about acquisition, in fact. It's trivial
to turn a piece of code with a name into something more flexible and
reusable.

> (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.)

Right, I knew this in the back of my mind as well, but was avoiding it for
similar reasons. :) It's another point in my argument for a smooth 
path of evolution.

> 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... :-( / :-)

I definitely learn from examples myself -- I think in fact most people
tend to work that way, including the key Zope folks. It's just that they've
already seen so many examples they've already gone through the abstraction
process, and it's hard to articulate your reasons if your understanding
has already turned into intuitions and gut sense..

> To present an example of something that *I* think of as a typical Zope
> service: a user authentication service.
[snip description I agree with as an example of a service]

A service is just a type of utility with an abstract interface registered
with the core. :)

> > 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.

He came up with ZPatterns, an advanced framework for Zope which in many 
people's opinions, including Phillip's own if I understand his previous 
posting right, had particularly um, innovative naming in some places. This
was somewhat confusing and hampered its uptake by some.

> > 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?

They'd be modules (or classes) looked up by a more advanced mechanism; it's
been discussed a number of times in the past for modules, I think most
recently here:

http://mail.python.org/pipermail/python-dev/2001-November/018525.html 

where among other things an acquisition-like mechanism for module importing
is proposed. Of course if one wants to look up classes or objects instead
of modules people generally roll their own registries and lookup mechanisms
instead; I know I keep doing stuff like that in my code.

Regards,

Martijn