Object serialization (was Re: [Zope-dev] FTP interface being worked on?)

[Fred Wilson Horch]

I hope folks don't mind if I resume the object serialization thread on
the mailing list.

Chris McDonough wrote:
> > 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?
> 
> Yes!  [...]  It's probably not even fair to call this kind of
> serialization "filesystem serialization" because it's the sort of
> representation of objects that can be used by FTP, WebDAV, etc.  It's just a
> human-readable representation of Zope objects that fits into a
> filesystem-like model that attempts to preserve most object information
> (although there's no guarantee that it won't be lossy).

The "no guarantee" lossy part bothers me.

For our purposes, we'd like to see lossless serialization that provides
full control over objects through FTP, WebDAV, etc.

Lossy serialization will cause problems for round tripping objects, i.e.
getting them out of the object database, updating them, then putting
them back in.

One of our goals is to be able to use CVS to track our updates and
distribute our object database.  We definitely do not want to be losing
information through serialization.

> > 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.
> 
> Yes, and this is great for XML export.  But I see filesystem serialization
> and XML export as different things.

No disagreement here.  I wouldn't want to have to deal with the XML
representation when I'm using an FTP or WebDAV client.

>  Zope already has a little-known XML
> format for representing python objects ("ppml", Python Pickle Markup
> Language), which is the format which XML exports are done in.  But when
> developers work with filesystem reps of objects, I'd hate for them to have
> to work with it.

Good point.  So the XML format stays monothilic (i.e an XML export of
the root object creates one big file, not a directory full of
sub-directories and files representing objects) and when you want to
deal with files and directories you don't get the XML format, you get
something else.

That means that each object needs to support two serialization formats:
XML and the "filesystem serialization" format.

> > 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

To elaborate, first, the existing FTP serialization format could be
enhanced to be this "filesystem serialization" format.

Second, the XML serialization format could be the basis for some
sophisticated client side management tools based on XML-RPC.  Unlike the
existing HTML (or XHTML) client side management interface, an XML
management interface could leverage XML libraries for parsing serialized
object data, and for communicating with Zope via XML-RPC. 

> Wow!  Looks like you're planning ahead.  I probably won't be available for a
> little while (I'm off this week), but hopefully I can get that proposal
> cleaned up and on the fishbowl and we can resume this discussion in that
> Wiki.

Okay, I'll try to deal with the Wiki.  But I have to admit that I find
the Wiki interface painful.  Is it okay to keep using the mailing list
for discussions like this?  I assume the keeper of the Wiki can copy and
paste useful bits into the Wiki as the mood strikes them.

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