Chris McDonough wrote:
Fred Horch wrote:
My major question is I don't understand the design decision to allow lossy representation. [...]
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 think the proposal says something like this.
The proposal states in part: If this API is not implemented by the developer, the result is undefined (XML pickle representation if allowed by the object on a per-object basis?). 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.
The whole point for us is to get full control of our objects through CVS.
That's one use, which is important to you. Another is to use Emacs or Dreamweaver on a representation of, for example, DTML methods on a filesystem, which is important to other folks.
The point of having potentially "lossy" representation of objects is to make it easier to work with them in these kinds of tools. Nobody wants to edit XML, AFAICT.
I see. I agree with the goal to have a representation that is easy to work with in emacs. Would it be possible to have a "lossless" representation that is also easy to work with? The current XML export format is "lossless" but hard to work with.
"Potentially lossy" also doesn't mean "leaky". It just means that folks who expose their objects to this sort of serialization can choose their own format, and if it represents the object adequately for their own use in both directions, it's good enough.
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. I completely agree with the point that we want to be able to work with representations of objects using tools like emacs and dreamweaver. In fact, we'd like to use emacs as our front end to CVS. The ideal situation would be to edit Zope objects in emacs, publish them to a Zope object database, test them (perhaps using a separate web browser like Netscape or Internet Explorer), and then once everything is working, commit the objects to a CVS repository (using emacs or from the command line).
If you want a lossless "morally binary" representation, it's probably best to use XML export, which is great for your purposes, because it already exists! ;-)
I've heard it said that all progress is due to the unreasonable man. So to do my part for progress, what I want is a lossless "morally plain text" representation. ;-) If the existing XML export really was great for our purposes, I'd be done! The problem is that everything comes out in one big monolithic file. That's not good for project management using CVS. (At least, as far as I can tell.) I think there is the potential for a really good solution that solves our need to manage our project via CVS, and to solve the greater need to enhance the Zope management interface to support tools that work with filesystem objects. I am about to jump into this project next week. I do want to stay in touch with anyone who is working on similar projects, so please keep in touch! I will post reports as I make progress in case anyone is interested. Thanks, Fred -- Fred Wilson Horch mailto:fhorch@ecoaccess.org Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8354