[Zope3-dev] event-meta.zcml placement? i18n-meta.zcml?

[Gary Poster]

Summary:

  - current "subscribe" becomes "directSubscribe" or similar

  - "subscribe" acts as you wish for local event services

  - I'm concerned about it though, especially for hub subscriptions.

And now the unabridged version...


Steve Alexander wrote:
 >
 >> I don't think "subscribeLocation" is a big improvement, though.
 >> Basically, you are substituting
 >>
 >>   eventService.subscribeLocation(locationAsTuple(myObj))
 >
 >
 > You can't use locationAsTuple like that. It only takes a location as an
 > argument. I guess you want getPhysicalPath(myObj).

Yeah, sorry, I was sloppy. :-(

 > In any case, it should simply be:
 >
 >   eventService.subscribeLocation(myObj)
 >
 > where myObj is context-wrapped, or
 >
 >   eventService.subscribeLocation(some_location)

ok...

 >>...
 >> Is the current code above really all that unpleasant?
 >>
 >> If the answer is yes :-)
 >
 > I would say "yes" :-)
 >
 > This means another import for client code.

Hm, this one doesn't convince me much. :-)

 > Also, it is not good for security.
 >
 > I'd better explain what I mean.
 >
 > When you offer programmers a choice between a verbose-but-secure call
 > and a simple-but-insecure call, they will generally choose the
 > simple-but-insecure one. So, our job as framework designers is to play
 > upon the laziness of software developers, and make it easier to write
 > secure code than insecure code, where we can do so.
 >
 > Subscription by direct reference is insecure, unless the person writing
 > the subscriber really knows what they are doing, because the notify() of
 > the subscriber is called without a proper context, and called in
 > response to third-party actions.
 >
 > This is tricky stuff, and in general, writing an event subscriber
 > shouldn't be tricky. So, I'd like the simple default
 > eventService.subscribe(object) to actually subscribe the object by
 > location, and to traverse to that location prior to notifying the object
 > of events.
 >
 > There could be a longer method name for subscribing directly. This will
 > be used much more rarely, as measured by lines of developer code

OK...

The global event service cannot act the way you describe, IMO.  It 
should not know anything about locations or traversal; moreover, since 
it is a global service outside of the persitent tree, clients can't 
subscribe persistently unless we write something to file or do something 
similar, none of which I think we want to do.

So one way around this is to have the basic event service interface not 
have a "subscribe" at all, but only a "directSubscribe", with the exact 
same doc string as the current "subscribe" method.  The local event 
service interface could then add a "subscribe" method that took a 
wrapped object or a path, as you described.

Is such a significant difference appropriate between two services of the 
same name (global "Events" vs. local "Events")?  We have tread this 
ground before, wondering if the global event service should be named 
differently than the local when doing service lookups...

I also don't like the fact that we cannot subscribe via objecthub hubid 
via this method.  As Ulrich and I discussed, though, an objecthub hubid 
is not unique: a reference to the objecthub and a hubid from that 
particular objecthub is the only unique combination.  Unless we make 
some hard rules about ObjectHub usage (which might be a *very* good idea 
for a number of other reasons, such as indexes) then an objecthub 
subscription needs to be a tuple of hubid and path to pertinent object 
hub, or somesuch.

(I'd very much like to say that object hubs cannot be nested without 
implying a completely new site, by the way: nested object hubs are a 
very scary thought to me.)

Does that imply a new method of "hubSubscribe" that remembers the path 
to the objecthub used and the hubid received?  Surely not: that leads 
down a path of method proliferation similar to what we saw in Zope 2 
code.  Can "subscribe" also take the tuple of a hubid and a wrapped 
object hub or a path thereto?  That sounds ugly.

Other options I can think of are magic and implicit.

I'll think about this some more, but meanwhile I've written enough to 
solicit a response, I think. :-)  Any ideas?

Gary