[Zope3-dev] service definition naming conventions

[Gary Poster]

On Monday 15 April 2002 02:39 pm, Jim Fulton wrote:
> Gary Poster wrote:
> > For most services, I am using three interfaces: a generic interface, a
> > placeless interface, and a placeful interface.  This is my naming
> > convention, using the factory service as an example:
> >
> > IFactoryService (generic interface for all factory services, used to
> > create the service definition)
> > IGlobalFactoryService (placeless subclass, file-system based)
> > ILocalFactoryService (placeful subclass, OFS-based)
> >
> > Similarly, that would be IRoleService, IGlobalRoleService, and
> > ILocalRoleService...and so on.
>
> Why do placeful and global services have different interfaces? I think
> they shouldn't.

(in the following, CA==Zope.ComponentArchitecture)

Actually, I got this ideally primarily from working with the 
CA.IServiceService, CA.Service, and Zope.App.OFS.ServiceManager.  
IServiceService is the actual pertinent "service" interface.  However, while 
both CA.Service and ...ServiceManager implement IServiceService, CA.Service 
has methods that deal with the fact that it is a registry-type solution 
("provideService" and so on) while ...ServiceManager has methods that deal 
with the fact that you bind held objects to service defintions.  This seemed 
like a reasonable distinction, and I felt it was a shame that there was not 
an interface to document the global and local versions.

It seemed quite likely to me, thinking about it further, that this kind of 
pattern might repeat itself it other placeful vs. placeless service 
distinctions--the need to simply register in a global service, but the need 
to interact with held objects for a placeless service.

In the cases of global and local subclass interfaces of the main service 
interface, the *only* real point would be to have the interface as 
documentation, since the interface-as-component-identifier role would be 
completely handled by the main service interface--so again, IRoleService is 
the service defintion, but IGlobalRoleService and I LocalRoleService provide 
additional documentation for the two flavors.

All that said, if you still don't buy it as a good idea then I happily 
concede--and thanks for thinking about it.

> Maybe your tripping over the fact that a number of the existing service
> interfaces are too big, including management, and well as query methods.

...well, maybe that's what I'm doing, but I don't think so...but I've been 
wrong many times before. :-)

> > Since, as I understand it, placeless ComponentArchitecture filesystem
> > services should go in Zope.ComponentArchitecture, the first two
> > interfaces go there, and the last one goes in
> > Zope.App.OFS.Services.LocalFactoryService.
>
> Again, I think this shouldn't apply to services.
>
> > I'd like to propose using this naming convention for all upcoming
> > services.
> >
> > More controversially, I want to rename all services and service
> > interfaces to follow this Global and Local naming convention. Thus (to
> > present the biggest and most potentially upsetting change first), I might
> > change
> > Zope.ComponentArchitecture.Service.Service to
> > Zope.ComponentArchitecture.GlobalServiceManager.GlobalServiceManager and
> > Zope.App.OFS.ServiceManager.ServiceManager to
> > Zope.App.OFS.LocalServiceManager.LocalServiceManager
>
> OK, you are refering to classes, not interfaces. This is fine with me.
>
> > I am using this naming convention now for my own work; if I get
> > *positive* feedback on this idea for renaming current services then I'll
> > proceed there in the latter half of the week.  I'm not necessarily
> > expecting positive feedback, though. :-)
>
> I'm OK with this naming convention for classes. I don't think it
> applies to interfaces.
>
> Jim

OK.  If you actively think it is a *good* idea, then I'll procede with 
renaming eventually.  If you could go either way, then I'll just use this 
convention for my own contributions until I hear of a more "blessed" approach.

Thanks.

Gary