[Zope-dev] FTP interface being worked on?

[Fred Wilson Horch]

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/RepresentingObjectsOnTheFilesystem)
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