[ZODB-Dev] Re: ZEO signal feature

[Jeremy Hylton]

>>>>> "TD" == Toby Dickenson <tdickenson@geminidataloggers.com> writes:

  TD> I think of it as a mechanism to extend the Storage interface.

  TD> (RPC is a detail of how ZEO happens to implement the signal
  TD> method)

Wouldn't it be more natural to extend the storage interface
dynamically by adding new methods?  The interface has evolved over
time using this approach, e.g. transactionalUndo().  The (optional) ZRS
methods like restore(), lastTransaction(), etc. are also implemented
this way.

  >> by passing method names to the signal() function.  It seems to
  >> duplicate the functionality in zrpc that determines what method
  >> to call based on the name passed in the RCP message. If so, it
  >> might be more natural to extend the RPC layer and provide a
  >> mechanism for the storage server to export more methods to the
  >> client.

  TD> Yes. That was exactly the approach I considered originally. This
  TD> very brief proposal might be familiar:
  TD> http://lists.zope.org/pipermail/zodb-dev/2002-May/002704.html

I believe I responded "Good idea" back then.

  TD> You are right that signal is a hack when viewed from the ZEO
  TD> point of view. I think it is a good one because:

  TD> 1. It was easy to implement in ZEO (and any future Storage
  TD> wrapper layers, not just those that provide network
  TD> transparency)

A getattr hook is easy to implement, too.  If the wrapped storage
declares its extended interface in some way, the hook isn't even
necessary.

  TD> 2. Suppose ZEO gains an extension method in the future. It will
  TD> be easy to understand how it should consume some extension
  TD> methods itself, and pass others on.

The ZEO protocol already has enough flexibility to accomodate
extensions without creating any confusion about whether a message is
intended to invoke a method.  The flags slot in the message allows
pretty arbitrary out-of-band messages.

  TD> 3. It clearly draws the line between the official Storage API
  TD> and extension methods.

This raises an interesting question for me: How would anyone invoke
extension methods on the storage?  ZODB application software isn't
supposed to interact with the storage directly.  It's supposed to use
the DB and Connection objects.

  TD> 4. There is no need for a storage to declare the names of all
  TD> its extension methods in advance.

I agree that it's helpful if extension methods aren't a static
property of the code.

  TD> 5. It closely parallels how COM deals with the same problem
  TD> using the IDispatch interface. The solution works very well in
  TD> COM. (at one time I considered naming this method
  TD> 'IDispatchInvoke' instead of 'signal'. That name is helpful to
  TD> anyone familiar with COM, but useless to anyone who isnt.  Are
  TD> there many COM people on this list?)

Wouldn't a Python object that proxied a COM object use a getattr hook?

  TD> Today the ZEO wire protocol transmits the method name in full
  TD> with every request. "zeoLoad", "commit", "abort", etc, all
  TD> travel as strings. Suppose at some point the ZEO wire protocol
  TD> is 'optimised' to give each method a single byte ID. Would my
  TD> proposed 'signal' implementation still seem bad?

If we did change the protocol, we would probably use a message flag
that indicated that the method name was encoded as an int rather than
a string.  This would allow encoded method names and explicit message
names to coexist.

Jeremy