Thanks for the pointers to the work others have done. You wrote in
> Tres Seaver has done some work on this with his FSDump product
> (http://www.zope.org/Members/tseaver/FSDump), although it only goes "one
> way" at the moment, and Steve Spicklemire has gone a slightly different
> route with his ZCVSMixin product
I will take a look at these. I see they are both Zope Products.
I had not planned to write a Product, but maybe I should reconsider.
For the FTP interface, I had planned to hack on the Zope internals
directly. And for the XML-RPC interface, I had planned to write a
separate client that could leverage the XML-RPC support already built
> I have a proposal up on the Digital Creations intranet which makes the
> proposal to leave serialization format up to each object, and gives some
> info about possible implementation strategies.
Get that proposal in the Fishbowl! ;-)
I wonder if yet another interface is really required. If you think
about it, isn't the FTP interface basically a file system serialization
format? All objects already support the FTP interface -- if we improve
it, then conceivably we can use standard FTP mirroring tools for
filesystem export and import.
Another serialized format that all Zope objects support is the XML
interface, which exposes all the objects' guts. With XML-RPC I
envisioned being able to improve on the FTP interface by adding things
like md5 checksums to determine if the local and remote objects are in
synch. I haven't looked too deeply, but presumably via XML you could
support all of the management functionality that is currently provided
by the HTML management interface. So you could build a client with a
rich feature set for managing Zope objects.
I understand your point about having each object's serialization "look
like" that kind of object, but isn't there also some value in the
consistency of XML representing every kind of object? For automated
tools, it seems like an XML representation is a great idea, and one that
could be exploited with a good client-side tool that understands the
Zope ODB DTD.
So I basically see three interfaces as necessary and sufficient:
1) XHTML - gets you started, can manage things with a browser
2) FTP - serialization to and from a filesystem
3) XML - the advanced management interface, easy to automate
I don't know much about WebDAV -- since we're a volunteer organization,
we are using free software where possible and I haven't seen much free
software that supports WebDAV. cadaver seems to work fine with Zope.
But I can easily see the combination of FTP + CVS providing us
everything we need. So in some ways WebDAV seems like an extra that
will be nice if and when there are clients that support it.
> I hope this email serves as a sort of overview
> about what we want to do about the problem at DC... it'd be great to be able
> to conserve resources and work on the same problem together.
Absolutely! We liked your Fishbowl process so much we are basing our
own development process on it. (For details of our process, check out
Fred Wilson Horch mailto:[EMAIL PROTECTED]
Executive Director, EcoAccess http://ecoaccess.org/
P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8354
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -