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