Hi Steve, You wrote:
Fred> We currently have two serialization interfaces in Zope: Fred> 1) the FTP interface, and 2) the XML export interface.
Hmm.. maybe I'm misuderstanding... which would/could you use for version control?
The XML interface.
It still seems to me that a blend of these could be developed that would work in all cases. An object could have a human readable part/aspect and 'the rest' could be captured as an xml bloblet. The 'human editable' part could just be what you get on the FTP interface (as you say), and the rest could be saved/restored to a 'auxiliary' file that would track other aspects of the object. Since objects could implement their own serialization, they could decide what aspects belonged in which part. Otherwise I can't help feeling that we'd have problems with duplicated versions, some xml/zexp, some human-readable that would inevitably stomp on eachother in any version control scenario. If all this could be worked in to the existing FTP/export/import system... there would be a minimum impact on existing interfaces.
That was my original sentiment, too. But Chris McDonough's proposal (http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst...) seems to allow developers to ignore any 'auxiliary' information that is not easy to serialize. I've come around to the viewpoint that the FTP interface (which in my opinion is what Chris' proposal is replacing) could just be used for editing objects one at a time. You can afford not to represent some information in this situation. It is just like through the web editing, but allows you to use emacs or Microsoft Word (or whatever client side tools you have that work with files on your filesystem).
Fred> FWIW, I'm working on tweaking the XML export/import code to Fred> serialize object hierarchies as directories and files, Fred> rather than exporting a single file.
Cool.. this sounds like a promising approach. I'd be interested in testing this..
The reason I'm working on this is that I think the XML serialization is what developers should use for source control / configuration management. There are really only two major problems with the existing XML serialization functionality that prevent us from using it with CVS: 1) everything is serialized to a single monolithic XML export file, and 2) you cannot update existing objects from an XML export file Hopefully I will have some code soon based on the existing export code that allows you to export any part of the object tree as a hierarchy of directories and files in Python Pickle Markup Language (ppml - the format used by the existing XML export), and import ppml files to update existing objects in the ZODB. By the way -- is it me, or is the current Import/Export interface broken? I tried to select multiple objects to export, but I can only get the first one to actually be exported. Fred -- 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