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.