[Zope3-dev] More name game suggestions

[Martijn Faassen]

Ken Manheimer wrote:

[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:
> 
> I'm also trying to get my bearings here, so i may have gotten scrambled -
> will be interested to hear the authoratative word.  However, those items
> in the cheat sheet are from my notes, from descriptions given pretty
> unequivocally.

Right -- my confusion is just an indication we're not there yet with the 
intuitive naming. Or perhaps my understanding of the component design;
it will take a while to absorb. Still.. 
 
> > > 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".
> >
> > > Contrast with Utility - name of Service is crucial, can have multiple
> > > services that implement same interface in the same place, distinguished
> > > by name.
> 
> For instance, from Step5/README.txt of the tutorial:
> 
>   component-management facilities. A common use of services is to
>   manage components. There are services for managing presentation components,
>   features, utilities and services. Services may provide other
> 
> So i suppose you could have different services for managing different
> kinds of components, and since they all implement the same interface, they
> would be distinguished by name.

Well, not quite; I'd say they have different interfaces in an important
sense; they return different types of components! I wouldn't say something
returning a presentation component has the same interface as something
returning a utility, even though they could share some innards and even
though the signatures (though perhaps not the types, if this were a statically
typed language) are exactmly the same..

> Similarly, different kinds of login authentications services would all
> implement the same interface, but convey different user data sources -
> distinguished again by name.  You could query by interface when you want
> to consult *all* the authentication services, but you may still need to
> get one with a particular name.

It seems useful to me under some circumstances to ask for a particular
named service, but generally I'd just want 'the login service we're
using for this object (or context), whatever it may be'. 
This allows one to configure the login service separately and keep it
from introducing a hard dependency in the code. I think that is one of the
points of services and using interfaces...right?

In case of a utility I usually have a pretty good idea of what I want;
I want the XML parser (even though this could be pluggable as well), I 
want the thing that if I put in these numbers it'll draw a graph of it,
etc. At least I thought this was the difference indicated, but I may be 
wrong. I generally see this latter type as just an object sitting in 
the object database in a certain place with a certain id that I can call
methods on; the object's class knows how to hook into the particular code
that does the stuff I want to do (and may be configured by the instance data).
At least that's how they commonly look like now; from an external method to 
full fledged Zope products.
  
A service could be similar, but is higher up in the hierarchy and can be
overridden by acquisition. This in particular is insufficient and too
chaotic, and needs better structuring.

I'll repeat the thesis that utilities and services are mostly quantitatively
different, not qualitatively, and that they should be designed so that's
easy to transition a utility into a service or vice versa.

This thesis may be entirely incorrect and I may be completely mistaken about
services and utilities. If so, someone let me know, and what's really
going on. :)

> As i said above, i'm among those still sorting this out, forgive me if
> i've increased the confusion!

No problem. We need some good confusion before we can get clarity, just
like getting lost somewhere can really increase your knowledge of the area.

Regards,

Martijn