[Zope3-dev] Re: ObjectHub Event names proposal

[Steve Alexander]

Godefroid Chapelle wrote:
> 
>> What would you think of just calling them "HubEvents"?
> 
> 
> I took your question 'à la lettre' and came to the following :
> 
> IHubEvent
> |
> +--IRegistrationHubEvent
> |   |
> |   +--IObjectRegisteredHubEvent
> |   |
> |   +--IObjectUnregisteredHubEvent
> |
> +--INotificationHubEvent
>     |
>     +--IObjectAddedHubEvent
>     |
>     +--IObjectRemovedHubEvent
>     |
>     +--IObjectMovedHubEvent
>     |
>     +--IObjectChangedHubEvent
> 
> Changes are done but not checked in. All test pass. (Ran 2001 tests in 
> 227.287s OK)

Great!


> 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 ?

An IObjectAddedHubEvent is simply an expression (usually by a folder 
management component) that something has been added, that has been 
directly translated by the ObjectHub from a location-specific 
ObjectEvent into an ruid-specific location-independent HubEvent.
The original ObjectAddedEvent was not sent with the ObjectHub 
particularly in mind as a recipient. Various other components might 
receive and process such an event.

An IObjectRegisteredEvent is an event that is sent intended to be 
received by an ObjectHub and its plugins.
A particularly savvy FolderManagement component might send these events 
out when particular objects are added. But I think it is more useful if 
there are ObjectHub Plugins that are responsible for listening to 
ObjectAddedEvents, and if appropriate, sending out 
ObjectRegisteredHubEvents to the ObjectHub, and the other Plugins.


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

The same kind of reasons as above. FolderManagement components should 
just be sending out ObjectEvents. That's all they know about.
We have a separate component for deciding when an ObjectRemovedEvent or 
ObjectRemovedHubEvent should prompt an ObjectUnregisteredHubEvent. This 
is most conveniently realised as a plugin in the ObjectHub.


> 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.

I think that with some careful analysis and so forth, we could reduce 
things to four such events. However, I think it will be easier to write 
and understand a variety of plugins if we keep the other events to 
explicitly represent what is going on. So, if a plugin is interested in 
registration, let it register for that event.
An important use-case here is when registration with the objecthub 
doesn't happen on the object being added to a folder, but instead 
happens as a result of some workflow transition, or other sort of state 
change.
An unregistration might occur for similar reasons. It might occur before 
an object is actually deleted from a folder.

Registration and unregistration are about declaring to the ObjectHub two 
things.

1: That we are interested in following events about the object
2: That we want the object hub to maintain an ruid-location mapping
    for this object

It makes sense for the ObjectHub to unregister objects, and send on 
ObjectUnregisteredHubEvents for ObjectRemovedEvents that are recieved 
for objects that it holds locations for. However, because 
ObjectUnregisteredHubEvents can be sent out otherwise, we still need the 
ObjectRemovedHubEvents.


> - 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.

Sure, it is possible to register plugins whose policies don't make sense 
working together.


> 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".

Yagni. The other plugin can simply listen for an 
ObjectUnregisterdHubEvent and veto that by raising exception. But I 
don't think this will generally be necessary.

In this case, the person responsible for configuring plugins within the 
objecthub has made a mistake by specifying incompatibly plugins. We 
shouldn't expect plugins to resolve such conflicts.
Such conflicts can be detected by reading the documentation for plugins, 
or perhaps by having some sort of inspectable activity log for an object 
hub, where you can see the sequence of events as prompted by an event 
received.


> 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 ?

yagni.


Thanks for your probing and insightful questions. :-)

--
Steve Alexander