--On Saturday, March 17, 2001 08:46:26 PM -0500 Fred Wilson Horch
<[EMAIL PROTECTED]> 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.
of the filesystem representation of a ZCatalog. What is lossless vs.
If the filesystem representation dumps evrything required to recreate a
of the catalog after a (perhaps lengthy) computation but doesn't actually
full current contents is that a lossless representation?
> The whole point for us is to get full control of our objects through
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
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
should be for folders, DTML, ZSQL, PythonScripts, etc. It's much less
what this should be for ZCatalogs, Racks (yeah DC probably doesn't care but
ZClasses, etc. It may be hard to come up with something better than XML
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
all metadata was a major goal. We can't live with the extreme
XML pickles to other tools. FSDump tries to capture all metadata
".props" files. I suspect that it is much closer to the eventual file
representation of Chris' proposal. FSDump has no read capability. At
from DC told me that Tres was worried that read capability would be a giant
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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -