[Zope3-dev] EventService, references, and subscription semantics

[Phillip J. Eby]

At 10:53 AM 2/26/02 -0500, Shane Hathaway wrote:
>Phillip J. Eby wrote:
>>Okay, maybe I'm missing something, but it seems to me like the simplest 
>>decomposition would be:
>>1. 'IReferenceable' - interface with a 'getReference()' method, returns a 
>>reference to the referencable thing.
>>2. 'IReference'  - subclass of IReferenceable, whose implementations' 
>>'getReference()' methods return 'self'.  Includes a 'dereference()' 
>>method, as well as '__eq__()' and '__hash__()' (general comparison 
>>doesn't really make sense for references, but dictionary lookup and 
>>equality checking would be useful).  'IReference' objects should be 
>>immutable and pickle-able, but should probably *not* be Persistent (the 
>>overhead would be wasteful).
>
>I see where you're going, but I think this is more complex, not simpler.

How so?


>Any object should be "referenceable", but the name IReferenceable suggests 
>the need for all referenceable objects to implement IReferenceable, which 
>I assume you did not intend.

No, it just requires that one be able to get an adapter that implements 
'IReferenceable'.  Objects that want to control how their references are 
generated *can* implement IReferenceable, however.



>Your URL ideas are good, but it would seem to me those ideas do not 
>require the "IReferenceable" interface.

Correct.  IReferenceable is only required for things that want to turn 
other things *into* references.  It is obviously not required in order to 
*use* a reference.

I think we agree on the basic points, but you appear to prefer a utility 
lookup, that may perhaps use an adapter, while I prefer an adapter lookup 
that may perhaps use a utility.

My reasoning for going the other way is simple: I want to be able to use 
IReference/IReferenceable *outside* of Zope and without my code being 
dependent on the ZCA, especially without being dependent on 
"utilities".  The kind of applications Ty and I write are generally not 
very "placeful", and are much more "typeful", if you will.  So supporting 
utility lookups is an extra burden for something that doesn't need it.

IReference and IReferenceable would be generally usable without Zope and 
the ZCA; all that would be required is the Interface package.  Yes, non-ZCA 
apps would have to implement IReferenceable in that case, but this doesn't 
impose any extra burden on ZCA apps.

Whether you go utility->adapter, or adapter->utility, there will still be 
two levels of indirection.  So why not take the one which gives the 
protocol more "legs"?  A non-ZCA application can simply require 
IReferenceable where it's needed, and a ZCA application can call 
getAdpater().  Either way, it just works, which is why I considered it 
"simpler".

Of course, you can get even simpler, and just require 'IReference'!  But 
this seems to me to just dodge the issue of how to get this reference for 
something which itself does not know how to get the reference.  Thus, 
IReferenceable and the adapter.  If you just adapt to IReference, this 
makes it harder to create an object that generates its own references, 
since IReference is a "wider" interface to implement than IReferenceable.

Anyway, I would like to see something that is useful beyond Zope and beyond 
TransWarp; a *lightweight* object reference protocol that could work across 
any Python application would be truly something to behold.  Let's not 
burden it with dependencies on either Zope or TransWarp if we can avoid it; 
after all, this could be used by Twisted, or any number of other Python 
frameworks and packages.

I realize that it may be outside scope for ZC, but it's not out of scope 
for the community, and I am more than willing to contribute code for both 
the generic naming package *and* the changes to ZCML to detect and act on 
the URL syntax wherever it currently takes import specifications.  And act 
as maintainer for the naming package.  I would expect the naming package to 
be homed in the Eby-Sarna CVS, with stable releases imported into the Zope 
CVS at the discretion of an appropriate Zope CVS committer.  Similarly, I'd 
incorporate such releases as part of TransWarp's installation package, as 
well as make it available standalone.