Bottom line is that storage methods need to be executed on both sides. I
don't think the storages need to care what or how objects are
transported nor what version of zope you are using so long as in the
end, the object is one that can be used by a storage method - and that
the storage methods are compatible with the older zopes (which seems to
be what you are concerned about). At least this is how I am looking at
it - whether it is zope 2 or 3, it should not matter if they are methods
that can act on ZODB and are suited to the zodb version. In any case,
thats the direction I have been going.
On top of it, who wants a transport that does only one thing, that can
get tired pretty fast. There are many more possibilities than exchanging
zodb data using a more generic transport. That's the other key reason I
tossed out my attempt to replicate ZEO directly using twisted - if you
want to think a bit beyond ZEO.
Jim Fulton wrote:
On Apr 28, 2007, at 9:13 AM, David Pratt wrote:
As far as compatibility, I am not sure the past always needs to equal
the future. It is probably the methods for zrpc that are important,
not the transport - at least that is my thinking.
I can use current ZEO servers with ZODB 3.2 clients running in very old
versions of Zope (2.6 and 2.7). This is extremely useful to me at this
point. I couldn't do this if I changed the wire protocol.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org