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:[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]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
