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

[Steve Alexander]

> 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