[Zope-dev] FTP interface being worked on?

[Dan L. Pierson]

--On Saturday, March 17, 2001 08:46:26 PM -0500 Fred Wilson Horch 
<fhorch@ecoaccess.org> wrote:

> I think lossless serialization should be an explicit goal.  If a
> developer doesn't provide specific object serialization methods, then a
> default method (perhaps XML) should be invoked that is lossless even if
> hard to work with.

I'm not sure what the caveats were that lead to the non-lossless guarantee. 
Think
of the filesystem representation of a ZCatalog.  What is lossless vs. 
non-lossless?
If the filesystem representation dumps evrything required to recreate a 
working copy
of the catalog after a (perhaps lengthy) computation but doesn't actually 
dump the
full current contents is that a lossless representation?

> The whole point for us is to get full control of our objects through
> CVS.

And grep and emacs, etc.  At least for us.  This is really the big issue.
If all you need is CVS, a "morally binary" XML representation can do.  Zope
already provides one, though it is not ideal for CVS.  If you want to be 
able
to use other file system based tools (a.k.a. normal development tools) then
you need a representation much closer normal text. It's almost obvious what 
this
should be for folders, DTML, ZSQL, PythonScripts, etc.  It's much less 
obvious
what this should be for ZCatalogs, Racks (yeah DC probably doesn't care but 
I do),
ZClasses, etc.  It may be hard to come up with something better than XML 
pickles,
which I agree should probably be the default if nothing better is specified.

Then there is metadata.  That leads into your next question:

> Can anyone tell me where my effort would best be spent?  Would it be
> best for me to start with FSDump or ZCVSMixin and corrupt them to serve
> my evil plans, or should I start from scratch based on the object
> serialization discussion we've been having (but with the explicit goal
> of lossless serialization, unlike Chris' proposal)?

The difference is that ZCVSMixin reads and writes XML pickles because 
capturing
all metadata was a major goal.  We can't live with the extreme 
unfriendlyness of
XML pickles to other tools.  FSDump tries to capture all metadata 
explicitly in
".props" files.  I suspect that it is much closer to the eventual file 
system
representation of Chris' proposal.  FSDump has no read capability.  At 
IPC9, someone
from DC told me that Tres was worried that read capability would be a giant 
security
hole.  I can't remember if that someone was Tres or not.  IMHO, the 
solution to this
probably involves forcing read to be invoked only from outside of Zope (or 
maybe only from a local machine login?).  I'm not sure how this would be 
done.