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