[Zope3-dev] Re: ObjectHub notes: removing objects

[Florent Guillaume]

Here's an attempt to describe how I understand all that.


As Steve said, the ObjectHub's contract is to keep a registration of
HubId <-> location mapping. So all that the subscribers of the ObjectHub
are interested first interested in is:

 - IObjectRegisteredHubEvent: there is a new object registered in the Hub,

 - IObjectUnregisteredHubEvent: an object has been unregistered.

Such a subscriber could be a metadata cache or indexing service, or a
relationship manager.


Now it appears that deciding what objects should be registered in the
ObjectHub may be delegated to plugins or outside utilities. These
utilities may "instruct" the ObjectHub, and I'm pretty sure using events
here would not be the correct thing, I'd use simply methods of the
ObjectHub. Just mentionning this to be sure.


There's another set of events that is interesting: for utilities that
track certain objects through their HubId, they may want for simplicity
to be relayed plain IObjectEvents through the ObjectHub so that they
receive the HubId info with the event. So here the role of the Hub would
be to forward all standard IObjectEvents (that concern an object that is
in the ObjectHub) as IObjectHubEvents to interested listeners. Here I
can see the use of IObjectModifiedHubEvent, IObjectMovedHubEvent, and so
on. A general mechanism to be able to forward any kind of event but with
additional info (HubId) would be nice.

The way I interpret the current discussion thread is, are
IObjectAddedHubEvent and IObjectRemovedHubEvent useful or are they
redundant with IObjectRegisteredHubEvent and
IObjectUnregisteredHubEvent?

I'd say they are not redundant. Yes, IObjectRemovedHubEvent implies
IObjectUnregisteredHubEvent (the object no longer exists) and
IObjectAddedHubEvent implies IObjectRegisteredHubEvent (we're hearing
about a new object from the ObjectHub so it must have been registered).
But the implication does not go the other way, so the events are not
equivalent.


Well, at least it clarified *my* thoughts on the matter :-)


Florent


Steve Alexander  <steve@cat-box.net> wrote:
> > Now to removing objects.  
> > 
> > In the current interfaces, it appears the desired behavior is for the
> > ObjectHub, when it receives an IObjectRemoved event, to remove the
> > object from its registry and send out an IObjectRemovedHubEvent, which
> > is a subclass of IObjectUnregisteredHubEvent.  
> 
> The event needs to go out before the HubId<-->location mapping is 
> removed from the Hub's registry, doesn't it?
> 
> Then again, if the location is part of the event, then I guess it doesn't.
> But, if we consider complex chains of events, the IObjectRemovedHubEvent 
> might be sent out while an IObjectChangedHubEvent is still being 
> processed. Would it be bad to lose the mapping in the Hub while another 
> event is still being dispatched?
> I think the Hub's event dispatcher needs to be re-enterant.
> 
> 
> > In the check-out's implementation, the behavior is for an IObjectRemoved
> > event to fire an IObjectRemovedHubEvent if the object is in the
> > registry, and stop--that is, the object's path is not unregistered
> > automatically.  The expected next step is that you have a subscriber
> > listening to IObjectRemovedHubEvents and, in most-to-all cases, sending
> > out, in reply, a request to the ObjectHub to unregister the given object
> > path.  This of course sends out an IObjectUnregisteredHubEvent.  The
> > events fired are then these:
> > 
> > (from source external to ObjectHub:) IObjectRemoved
> > (from ObjectHub:) IObjectRemovedHubEvent
> > (from hypothetical ObjectHub subscriber: message objectHub.unregister)
> > (from IObjectHub:) IObjectUnregisteredHubEvent
> > 
> > PROPOSAL: keep the current implementation, and change the interface to
> > describe it. 
> > 
> > PRO: I can think of a use case for it.  On object removal, we might want
> > to do more complex behavior than merely either removing the link or
> > raising an exception.  We might want to allow the removal but make a
> > "ghost" placeholder to which the object-hub-related information can
> > still point, for instance.  
> > 
> > CON: (1) delegating the *essential* behavior of what to do when an
> > object is removed to a plugin seems a bit risky.  (2) it's not a direct
> > parallel to what I proposed to do for object added events.
> 
> Let's think about the Hub's responsibility in this case. The Hub is 
> supposed to keep an up-to-date mapping from HubId<-->location for all 
> registered objects.
> If an object is removed, then it no longer exists at its previous 
> location, therefore the Hub should remove the object's entries from the 
> mapping. Removing an object's entries from the mapping is another way of 
> saying "unregistering".
> 
> So, two things have happened that subscribers will be interested in:
> 
> * An object has been removed
> * An object has been unregistered
> 
> Making this unregistration optional would break the Hub's contract to 
> keep track of HubId<-->location.
> 
> This is a different kind of thing to when an object is added. In that 
> case, an object has been added somewhere, and we want to allow a plugin 
> to decide whether or not it should be registered with the Hub. In the 
> case discussed above, the object being removed is already registered 
> with the Hub, so the Hub must do something about its removal.
> 
> --
> Steve Alexander
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
> 


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com