[Zope-dev] FTP interface being worked on?

[Chris McDonough]

> I had not planned to write a Product, but maybe I should reconsider.
> For the FTP interface, I had planned to hack on the Zope internals
> directly.  And for the XML-RPC interface, I had planned to write a
> separate client that could leverage the XML-RPC support already built
> into Zope.

It's possible to use Products for all sorts of stuff, even overriding
methods and attributes of objects in the core (this is how Hotfixes work).
It's hard to maintain a product that does this though.

> >  I have a proposal up on the Digital Creations intranet which makes the
> > proposal to leave serialization format up to each object, and gives some
> > info about possible implementation strategies.
>
> Get that proposal in the Fishbowl! ;-)

Yup.

> I wonder if yet another interface is really required.  If you think
> about it, isn't the FTP interface basically a file system serialization
> format?  All objects already support the FTP interface -- if we improve
> it, then conceivably we can use standard FTP mirroring tools for
> filesystem export and import.

Yes!  Take for example PythonScripts.. they already support such a
serialization for their content... even though there's info in the bindings
tab and the arguments list, it's placed into the serialization in a
reasonable way.  This is the sort of thing I'd like to see generalized for
all basic Zope objects, but with better functionality for security settings
and properties.  It's probably not even fair to call this kind of
serialization "filesystem serialization" because it's the sort of
representation of objects that can be used by FTP, WebDAV, etc.  It's just a
human-readable representation of Zope objects that fits into a
filesystem-like model that attempts to preserve most object information
(although there's no guarantee that it won't be lossy).

> Another serialized format that all Zope objects support is the XML
> interface, which exposes all the objects' guts.  With XML-RPC I
> envisioned being able to improve on the FTP interface by adding things
> like md5 checksums to determine if the local and remote objects are in
> synch.  I haven't looked too deeply, but presumably via XML you could
> support all of the management functionality that is currently provided
> by the HTML management interface.  So you could build a client with a
> rich feature set for managing Zope objects.
>
> I understand your point about having each object's serialization "look
> like" that kind of object, but isn't there also some value in the
> consistency of XML representing every kind of object?  For automated
> tools, it seems like an XML representation is a great idea, and one that
> could be exploited with a good client-side tool that understands the
> Zope ODB DTD.

Yes, and this is great for XML export.  But I see filesystem serialization
and XML export as different things.  Zope already has a little-known XML
format for representing python objects ("ppml", Python Pickle Markup
Language), which is the format which XML exports are done in.  But when
developers work with filesystem reps of objects, I'd hate for them to have
to work with it.

> So I basically see three interfaces as necessary and sufficient:
>
> 1) XHTML - gets you started, can manage things with a browser
> 2) FTP   - serialization to and from a filesystem
> 3) XML   - the advanced management interface, easy to automate
>
> I don't know much about WebDAV -- since we're a volunteer organization,
> we are using free software where possible and I haven't seen much free
> software that supports WebDAV.  cadaver seems to work fine with Zope.
> But I can easily see the combination of FTP + CVS providing us
> everything we need.  So in some ways WebDAV seems like an extra that
> will be nice if and when there are clients that support it.
>
> > I hope this email serves as a sort of overview
> > about what we want to do about the problem at DC... it'd be great to be
able
> > to conserve resources and work on the same problem together.
>
> Absolutely!  We liked your Fishbowl process so much we are basing our
> own development process on it.  (For details of our process, check out
>
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/docs/tech-process.txt?rev=1.2&
content-type=text/x-cvsweb-markup&cvsroot=ecoaccess
> )

Wow!  Looks like you're planning ahead.  I probably won't be available for a
little while (I'm off this week), but hopefully I can get that proposal
cleaned up and on the fishbowl and we can resume this discussion in that
Wiki.

Thanks!

- C