[Zope3-dev] ObjectHub notes: removing objects

[Gary Poster]

On Fri, 2002-10-18 at 11:34, Steve Alexander wrote:
> 
> > Hmmm... can someone explain why adding and deletion have been seperated 
> > from registering and unregistering?
> 
> They are different things.
> 
> When you add an object to a folder, you don't necessarily want to 
> register it with an object hub.
> When you remove an object from a folder, it isn't necessarily registered 
> with an object hub, so unregistration is not necessarily necessary.
> You will want to register an object with an objecthub at an arbtrary 
> point during its life. For example, when it reaches a certian point 
> during a workflow, or when it is moved to a particular place.
> You will want to unregister an object with an object hub at an arbitrary 
> point during its life. For example, when it reaches a certain point 
> during a workflow, or when it is moved to a particular place.

I'm no longer sure where I stand on this.  I'm leaning towards Chris'
position.

While I agree with you, Steve, that the meaning is in fact different
between the two objects, I cannot think of an excellent use case for an
Object Hub client that actually *cares* about this distinction.  If I am
a relationship service, if something tries to break the registration of
an object for which I have a relationship, I am equally concerned about
the event (I must delete the relationship, or I must raise an error
stopping the registration removal) as if the object were being removed,
and my actions are the same.  If I am a metadata cache service, again,
my actions are identical in both cases (remove the metadata).  If I am
an indexing service, my actions are identical (remove the pertinent
hubid from my indexes).

Is there a practical difference to the *consumers* of these events,
despite the fact that we see one from the outside?  Don't an object
removal and a workflow-related unregister call both require the same
exact processing from all ObjectHub clients?

Here's the best use case I've been able to come up with for the
distinction. If we want a cascading delete from a relationship
service--that is, a relationship type set up to remove the paired object
if one object in a relationship is deleted--then unregister and remove
might have important implications:  an "object removed" should spark the
cascade delete, but an "object unregistered" should probably raise an
error--since presumably, if the objects are really tied that closely
together, the breaking of the relationship makes the paired object
unimportant or uninterpretable.  But if that logic holds, can't we just
extend the logic and say that the "object removed" event is unnecessary,
and we cascade delete on the "object unregistered", because the
connected objects must be unimportant/uninterpretable now anyway?  

I don't think the distinction buys us much.  Is it enough to keep?

I imagine Chris agrees with himself. ;-)  Have I convinced you, Steve,
or anyone else?

Gary