I think the only good reasons we have right now for having filesystem-compatible serialization are to make Zope content editable via common tools in a way that makes sense to people not used to (or comfortable with) the object database, and to give people a plausible way to put a Zope site under source control. Are you thinking that we would build client-side tools to recognize an XML representation of a subpart of a site? ----- Original Message ----- From: "Karl Anderson" <karl@digicool.com> To: "Chris McDonough" <chrism@digicool.com> Cc: "John D. Heintz" <jheintz@isogen.com>; "Fred Wilson Horch" <fhorch@ecoaccess.org>; <zope-dev@zope.org> Sent: Thursday, March 22, 2001 8:17 PM Subject: Re: [Zope-dev] FTP interface being worked on?
"Chris McDonough" <chrism@digicool.com> writes:
I don't think it's reasonable or wise to impose any "master structure" for filesystem serialization of bodies of objects. Each instance (or perhaps each class) should define how best to serialize itself to disk. Representations between classes are likely to be radically different. A place for standardization is in the "properties" file(s) which accompany each object rep... this is likely to be XML or another structured variant.
Is there a motivation for using serialization to provide an editable "god's eye view" of all or part of a Zope site?
That is, provide a two-way XML serialization at any stage of the managed hierarchy of a site? That way, XML tools could be used as stream editors at any level, to the extent that the serialization is understandable.
So, for example, we'd have ways to not just alter a template or content that gets templatized, but the containers that organize them, and related metadata or content that isn't as near.
This links well with the standardization that you mention - objects can have arbitrary serialization formats, but if certain attributes that we're interested in are recognizable, those attributes could be edited on a containerwide level. So, if we had arbitrary objects that we wanted to have an effect on content or display, the same XML tools could be used to manage them all, limited only by the ability of those tools to slog through a level of the hierarchy.
This is kind of stream-of-consciousness talk, and might be more silly than realistic; certainly, if the objects didn't guard how they could be updated, a misconfigured tool could waste them without warning.
There's a similar project called psilib that was discussed in xml.com: <http://www.xml.com/pub/a/2000/03/22/psi/index.html>
-- Karl Anderson karl@digicool.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )