Wanted to follow up on Steve's points.

He wrote in part:
> [...] It seems to me that the current import/export
> mechanism is actually pretty close to what we need for serialization.[...]
> A) All objects are faithfully encoded and saved on the filesystem
>   in a text format that any configuration management system can
>   use and track. [...]
> B) Whole object hierarchies can be saved in a simple file, moved
>   to any other zope instance (via checkin/checkout) and instantiated. [...]
> C) It's possible (through a hack[1]) to make simple objects 'diff'able
>   so that all the metadata that's in the current xml export rep doesn't
>   get in the way too much. [...]
> There are also a few not-so-nice properties:
> D) The current xml representation use by xml import/export is morally
>   binary, in the sense that you can't easily edit/manage it with
>   ordinary editors etc.
> E) There is no simple way to separate the contents of a containerish
>   object from the container.
> [...] Imagine the following:
> A 'serialization' interface is invented that objects could implement
> that preserve A-C, and, optionally, fix D-E. If no such interface
> is found, the current export method is invoked. [...]

I don't know if we need just one serialization interface that tries to
solve all five issues.

We currently have two serialization interfaces in Zope:

 1) the FTP interface, and
 2) the XML export interface.

Seems to me that the FTP interface could be generalized as the "lossy"
serialization interface that is "morally human readable" and the XML
export interface could be tweaked a bit as "lossless" but "morally

The FTP interface would be used when you want a representation that can
be edited by hand.  It solves C, D and E, but not A and B.

The XML interface would be used when you want a representation that can
be manipulated programmatically.  It solves A and B, but not C, D and E.

FWIW, I'm working on tweaking the XML export/import code to serialize
object hierarchies as directories and files, rather than exporting a
single file.


P.S.  The link Karl sent (http://www.thetwowayweb.com/theXmlFiles) is
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 - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to