[Zope3-dev] Tabling the name game?

[Martijn Faassen]

Phillip J. Eby wrote:
> Hrm.  So far I haven't heard any reason *why* these distinctions even 
> exist.  The service vs. utility dichotomy seems kind of weird to 
> me....  like dividing components into ones with pink polka dots versus ones 
> with purple stripes.  What if I want one with purple polka dots?  Do we 
> need words for ones with pink dots and purple stripes, but no words for 
> ones with purple dots?  And if so, how precise should these words 
> be?  Should pink stars or triangles be considered similar enough to polka 
> dots to be considered the same thing?  Argh!

I think we should call utilities 'utility services' or just 'services', and
we can rename 'services' into 'core services', and now it's instantly clear
that 'core services' will always be supported by Zope and they'll always
be there, while plain services are up to the developers building on top
of Zope. The same APIs can be used to get at both, which eases the learning
curve.

> In other words, the names talked about so far do not seem to completely 
> cover nor clearly divide the conceptual space of "component".

Well, we have 'adapters' too, and of course content components. But those
are apparently more clear than the utility/service distinction.

[snip]
> Meanwhile, describing what particular components actually do or don't do 
> will probably be more helpful than trying to define broad categories of 
> components up front.  It may lead to some repetition or redundant 
> descriptions initially, but it will *really* help those of us who are 
> struggling with the terminology right now.  Which, I think, is nearly all 
> of us who haven't been living in contact with the NewReligion during its 
> conception and gestation.

I think working up from examples is a good idea, though I think it's 
useful to keep some of the distinctions in mind nonetheless, and not
start from scratch entirely with any categorization. Without trying to
categorize the things you encounter you can end up with a mess too, so
I think it's useful that we're starting out fairly early with this.

Regards,

Martijn