[Zope3-dev] ObjectHub Event names proposal

[Gary Poster]

Hi, Godefroid.

On Tue, 2002-07-30 at 13:02, Godefroid Chapelle wrote: 
... 

> I think it is necessary to rename IRuidObjectEvent to IHubEvent and 
> RuidObjectEvent to HubEvent...

I think I like those better, yes, and it matches up with the rest of the
changes.  I don't think we will necessarily want to reuse these specific
events for ruid-type systems outside of the object hub, so this is both
shorter and arguably more descriptive.

> but I do not know what I am supposed to do as cvs commands.
> 
> I think should be
> 
> cvs add IHubEvent.py
> cvd remove -f IRuidObjectEvent.py
> cvs commit
> 
> Can you confirm ?

as fas as cvs is concerned, yes, it looks like that would do the job
(except for typo "cvd" in second line :), given that the code itself has
been fully updated.  However, by doing the "remove -f" I assume you
still have IRuidObjectEvent.py in your local directory (that's the only
time "-f" is pertinent, I believe).  The "-f" option is convenient
(removing both your copy and the one in the repository), but you might
want to delete the file first in your own copy, rerun the tests to make
sure all is well, and *then* do the steps you listed above (but this
time without the "-f" option).  Just a precaution.
 
> Further, when trying to document the interfaces (especially when trying to 
> differentiate RegistrationHubEvents and NotificationHubEvents), I came to a 
> few questions :
> 
> - What is the semantic difference between IObjectRegisteredHubEvent and 
> IObjectAddedHubEvent ? IOW why do we need both ?

Added: a new object is created
Registered: an object is registered in the hub

The distinction might be important if an already-existing object is
registered in the ObjectHub.  That is, 
* if an object that the hub cares about is *created*, both an "added"
and a "registered" event is disseminated.  
* If the hub is merely newly-informed of an already-existing object,
only a "registered"  event is sent.

Perhaps it would be worth pondering making "Added" a subclass of
"Registered"?  So only one event would need to be propagated on an
addition, an "Added" event, but this would in fact be a subclass of
"Registered" so any interested parties to registration would also get
their message.  

We would need to go through our use cases with these, I suppose.  Can we
conceive of a usecase for a plugin that cares about object added events
but not object registered events?  

I think you all had a number of use cases and design decisions in the
sprint.  I'd love to be able to see some of the thoughts you all
had--perhaps on the Zope3 wiki?

> - What is the semantic difference between IObjectUnregisteredHubEvent and 
> IObjectRemovedHubEvent ? IOW why do we need both ?

Parallel discussion to the above.  Subclass, perhaps?

> I have the feeling that 4 events (registered, unregistered, moved, 
> modified) should be enough and that we do not need the somewhat artificial 
> separation I had proposed.

As above; maybe you're right.

> - During sprint, we took the responsibility to register to 
> registration-plugins. This implies that those get the responsibility to 
> unregister. This implies that one of the plugins which would like to 
> unregister could step on the toes of another plugin which wants to keep the 
> object registered.
> So we need to implement a mechanism where a plugin would emit a 
> IObjectUnregisterQueryEvent to which other plugins should be able to answer 
> (how ?) with a "yes, go on, unregister" or a "no, stop, I still need this 
> object".

I wasn't part of this discussion, so I'm a little lost, and I'm also not sure
that the implications you list are necessities.  This sounds like we'll need
some feedback from Steve, or maybe we can hash some of this out on a wiki.

> This leads to the next question, is there a similar mechanism in the 
> current Event service and would it not being needed for other situations ?

The event service simply relies on something throwing an exception if it 
doesn't like what's going on; this cancels the whole transaction, and we're
done.  There's no parallel concept of plugins for the event service either--
just subscribers, and messages to propagate given events--so I don't know 
if a similar mechanism is necessary.

Gary