[ZODB-Dev] Re: ZEO signal feature

[Toby Dickenson]

On Monday 23 Sep 2002 5:07 pm, Jeremy Hylton wrote:
> I'm trying to clear out the backlog of ZEO todo items in hopes of
> getting another beta release out soon.  I'd like to accommodate the
> use cases that lead to the signal code, but I wonder if we could
> consider some other alternatives.
>
> What exactly is the use case for the signal feature?  It looks like a
> mechanism to extend the RPC interface

I think of it as a mechanism to extend the Storage interface.=20

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

> 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=20
> and provide a mechanism for the storage server to export more methods
> to the client.

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


You are right that signal is a hack when viewed from the ZEO point of vie=
w. I=20
think it is a good one because:


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

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

3. It clearly draws the line between the official Storage API and extensi=
on=20
methods.

4. There is no need for a storage to declare the names of all its extensi=
on=20
methods in advance.

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


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