[Zope-dev] FTP interface being worked on?

[Chris McDonough]

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

Which ones?

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

XML doesn't play with diff very well... additionally, XML isn't as easy to
work with as what I think it should look like.  For example, I'd rather
serialize a PythonScript into:

   def foo(self):
       print "hi!"

than...

   <?xml version="1.0"?>
     <pythonscript>
        <function>
           <functiondef name="foo">
             <arg>self</arg>
           </functiondef>
           <functionbody>
            print "hi!"
           </functionbody>
         </function>
      </pythonscript>

The former is easier to understand.

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

Yes.. anything that works well with diff and CVS and is recognizable by a
human.  PythonScripts should be serialized to something that looks like a
regular Python script.  Images should look like images, etc.  The directory
tree generated should look as much as possible like a normal filesystem.

I can see a middle ground that's more parser-friendly, but it's sorta a
different goal AFAICT.  An XML rep might let you use something like XSLT to
do some transformation across all the representations of the objects that a
more human-friendly representation wouldn't, but it would lose lots of other
utility which I think is more aligned with the goals of the proposal I put
up... that's not to say that a middle-ground XML representation somewhere
between "ppml" (XML export format) and human-friendly isn't something that's
desirable for lots of folks, it's just not what the proposal was about.