[Zope-dev] FTP interface being worked on?

[Karl Anderson]

Chris McDonough <chrism@digicool.com> writes:

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

Client-side tools, no.  I'm thinking that exporting to XML would allow
existing tools to recognize and manipulate a subpart of a site.

I'm basically agreeing with you - "common tools" for manipulating text
sounds like parsers to me.

I'm not sure why XML is considered less readable than an unknown
format for Zope object serialization; I guess I haven't seen what's
being considered.  But it seems to me that for humans, XML might lose
by a little, but for any type of mediated or batch processing, XML
wins by a lot.  Parsers are standard enough that their APIs are easy
to learn if you've played with them before.

Random human-editable text formats sounds like StructuredText; when I
think of StructuredText I think "simple DOM serialization".

Is there a particular set of tools or editing paradigms that we have
in mind when we say that a non-XML representation is suited for client
side tools?

This is the way that Manila seems to be doing it:
http://www.thetwowayweb.com/theXmlFiles

-- 
Karl Anderson                          karl@digicool.com