[Zope-dev] FTP interface being worked on?

[Chris McDonough]

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