[Zope-ZEO] ZEO-0.2

[Greg Ward]

On 10 May 2000, Jim Fulton said:
> Here's a tar ball for ZEO 0.2.
> 
> After extracting it, see ZEO-0.2/ZEO/README 
> and ZEO-0.2/ZEO/CHANGES.txt.

OK, I've got it working if working means "the server is running".

A couple problems so far.  First, two minor annoyances that I didn't
bother to complain about with ZEO 0.1, but are still present:

  * no "stop" script -- if it's as simple as 
    putting the Python equivalent of "kill `cat var/ZEO_SERVER.pid`" in
    "stop.py" then I'd be happy to contribute that

  * if a client dies while its connection is open, the server spews
    a lengthy error message to its stderr, even though it has
    supposedly "gone daemonic" (I have not set the logging environment
    variable, so I assume this is a "feature")

New problems:
  * keyword arg "datadir" in ClientStorage constructor changed to "var",
    which means I had to hack in a dependency on
    ClientStorage.__version__ where we call this.  Yucky, but this is
    only at one spot in the code, and it'll go away when we don't care
    about ZEO 0.1 anymore.  I suppose API upheaval is to be expected
    with version numbers < 1.0, but I'll grumble all the same!

  * and now one that looks like a real bug: I run one of my test client
    scripts, and it dies almost immediately with this (elided)
    traceback:
      [...]
      File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 163, in _initialize_zeo
        self._initialize_zodb( extra_info, storage = client_storage)
      File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 149, in _initialize_zodb
        self.db = DB (storage)
      File "/export/www/zope/Zope-2.2cvs/lib/python/ZODB/DB.py", line 125, in __init__
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 224, in registerDB
        self._startup()
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 145, in _startup
        if not self._call.connect():
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 149, in connect
        self.aq_parent.notifyConnected(s)
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 159, in notifyConnected
        self._call.finishConnect(s)
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 153, in finishConnect
        SizedMessageAsyncConnection.__init__(self, s, {})
      File "/www/zope/Zope-2.2cvs/lib/python/ZEO/smac.py", line 100, in __init__
        SizedMessageAsyncConnection.inheritedAttribute(
    TypeError: too many arguments; expected 2, got 3

    (Sorry for the wide lines, but that's life with tracebacks.)

    Anyways, to my ignorant eye it looks as though the traceback tells
    the truth: the SizedMessageAsyncConnection constructor starts off
    like this (line 100-101 of ZEO/smac.py):
        SizedMessageAsyncConnection.inheritedAttribute(
            '__init__')(self, sock, map)

    Based on the superclasses of SizedMessageAsyncConnection, I assume
    this will call asyncore's constructor.  But asyncore, at least in
    the Python 1.5.2 and current CVS library, has a constructor like
    this:
	def __init__ (self, sock=None):

    ...ie. no 'map' parameter there!

    A-ha!  I see -- smac.py does "import asyncore", when it should
    probably do "from ZServer.medusa import asyncore", since I see
    an asyncore.py with a 3-argument constructor in ZServer/medusa.

    Looks like a bunch of other modules in ZEO 0.2 also "import
    asyncore", which means they will get the standard library version.
    Jim, is my interpretation correct?  If so, I'll submit a patch
    straightaway.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367