Hi Chris, Thanks for the pointers to the work others have done. You wrote in part:
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 (http://www.zope.org/Members/sspickle/ZCVSMixin/).
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 into Zope.
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 http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/docs/tech-process.txt?rev=1.2&... ) -- Fred Wilson Horch mailto:fhorch@ecoaccess.org Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8354