"Dan L. Pierson" wrote in part:
> > I think lossless serialization should be an explicit goal.
>  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?

Yes, in my book (as long as original and recreated copies of the catalog
are functionally identical).  I'm using lossless in the sense it is used
in the compression field.  If you can recreate the same objects from the
representation (even if it requires several computational steps) then
the representation is "lossless".

A "lossy" representation would mean that you lose some piece of
information that is essential to getting back to the original state of
the object database.

For images, JPEG is a lossy compression scheme, which means it is one
way.  If you convert a TIFF to JPEG, then you can't go back to the exact
same TIFF.  By contrast, PNG is lossless.  You can convert from TIFF to
PNG and back to TIFF and get the exact same TIFF.

My concern is that if the plain text serialized format is lossy, it will
be one way only.  That is not good for us.  To preserve the round trip
ability, we need a lossless representation.

> > The whole point for us is to get full control of our objects through
> > CVS.
> And grep and emacs, etc.

Yes.  CVS is the principal driver for us, but grep and emacs are
important too.

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

Good points.

I'm eager to hear from anyone else with a perspective on this before I
start coding something up.

Fred Wilson Horch                       mailto:[EMAIL PROTECTED]
Executive Director, EcoAccess           http://ecoaccess.org/
P.O. Box 2823, Durham, NC 27715-2823    phone: 919.419-8354

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to