[Zope-dev] FTP interface being worked on?

[Chris McDonough]

Fred wrote:
> > I guess I'm voting to rewrite this sentence:
> > 
> >   If this API is not implemented by the developer, the
> result is
> >   a default serialized representation (perhaps XML
> pickle) on a
> >   per-object basis

I think this makes sense.

> > Maybe the issue is semantics.  I think "potentially
> lossy" ==
> > "potentially leaky".  Even a small leak would cause
> problems for us. 
> > Maybe it wouldn't cause problems for others.  But it
> sure seems like it
> > would be possible to create a solution that works for
> everyone.  Namely,
> > a lossless representation that is easy to work with.

This is possible probably for many objects.  DTML Methods,
for instance, are basically just big bags of text with some
security settings and other associated metadata.  Recreating
them losslessly from a filesystem representation is pretty
easy.  ZCatalogs, on the other hand, have lots of state,
which is hard to adequately represent in anything but a
morally binary representation.  Maybe we won't even try to
make it editable, and we'll choose to use XML for these.

John wrote:
> I'd first like to say that I applaud the goal stated in
> the previous line!
> 
> I think there are two key problems with achieving it.
> 1) Because everyone writing extensions for Zope can
> define their own 
> data structures it make it very difficult to store them
> anywhere but an 
> object database.  I think this problem has nearly the
> same complexity as 
> figuring out the RDBMS table structures necessary for all
> the Products 
> and builtin objects in Zope...

Yes... luckily, because we have OO and polymorphism, we
don't have to do this!  ;-)

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.

> 2) A lesser problem is when trying to edit the serialized
> "files". 
> Because objects are methods and state how you modify an
> object can be 
> guided if not controlled.  When we have serialized the
> objects in a Zope 
> system to files, we have exported only the state of the
> objects in the 
> ZODB.  We then have to live with the ability to foul up
> invariant across 
> many objects by changing some data in the serialized
> format.  A good 
> example would be ZCatalogs.  When some piece of data
> changes the code 
> can automatically call reindex(), if I'm editing a file I
> might not know 
> that I need to change other files due to runtime
> dependencies.

Yup... it's probably easiest to make ZCatalogs a black box.

> a) XML is structured enough that it can reliably hold the
> data from the 
> ZODB.  The current XML dump is not useful for this - it
> would need to 
> create individual files and folders to represent
> containment.

This is pretty easy right now.  Ten lines of recursive code
can walk the whole tree if necessary and export only leaf
objects.
 
> b) A hybrid XML and custom dump solution.  An Image for
> example could 
> dump out as a binary image file with meta-data in a
> similiarly name XML 
> file.

Yes, each object should make its own policy regarding its
body.  Its metadata format should be standardized, however.