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" <[EMAIL PROTECTED]>
To: "Chris McDonough" <[EMAIL PROTECTED]>
Cc: "John D. Heintz" <[EMAIL PROTECTED]>; "Fred Wilson Horch"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 8:17 PM
Subject: Re: [Zope-dev] FTP interface being worked on?
> "Chris McDonough" <[EMAIL PROTECTED]> 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
> 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:
> Karl Anderson [EMAIL PROTECTED]
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -