[Zope3-dev] thoughts from the peanut gallery

[Gary Poster]

A few thoughts from a metaphorical hobbit among giants, or some such, after
said hobbit has carefully perused the tutorial, the component architecture
wiki and the Zope3 mailing list archives.

THE PRESENT:

Wow--this design is, pardon the phrase, very pretty.  Wiser heads than mine
have said so as well, but here's a small gun who is also pleased and very
impressed.  *Pretty*.

BEATING A DEAD HORSE:

I know the renaming decision is made for now towards "adapter", but for what
it's worth, "feature" made perfect intuitive sense to me on first reading
the tutorial and code, and I continue to prefer it.  This doesn't even have
anything to do with GoF--my copy is yet to be read thoroughly--but merely a
gut reaction I share as perhaps a representative of "the little people".

THE FUTURE--VERSIONING:

One of the things I love about the current design is how explicit and simple
the contracts are--the traversal setup in the tutorial was very nice, for
instance.  Simple in interface, while allowing *huge* flexibility in
implementation.  While I'm sure more complexity will creep in in these
contracts as Zope3 and the corresponding tutorial examples become more
fleshed out, it seems the design goal of explicit and simple contracts is
beautifully met so far.

Has versioning support as a similar simple contract system been discussed?
The disadvantage would be that newly-designed classes would not have
versioning unless explicitly set up.  An advantage might be that a simple
interface--for instance, requiring an object implementing versioning to have
a "createBranchCopy" and a "mergeBranchCopy" function that spits out its own
editable object on the one hand and knows what to do with an edited copy
handed to it on the other--could be put to whatever use is desired.  Out of
the box implementations provided, of course, but replaceable.  Setting this
kind of basic versioning support up in the product's XML file would also be
pleasantly explicit, much like the rest of the XML format so far.

My exact interface suggestion may be naive, but I hope the simplicity point
might be worthwhile, and the idea of making versioning a more fine-grained
and explicit tool.

In favor of the exact interface I suggest, by the way, it would be very nice
if version objects of any given object could theoretically be placed
anywhere in storage while they are being edited.  This would allow edit
requests by non-owners.  The merging might be a tad tricky, but it seems
this is an implementation issue that has many prior examples to follow (he
said blithely).

THE FUTURE--GUID:

I suspect that GUID Zope approaches are regarded with some suspicion--refer
to the object by path and be happy, or use a RDBMS, is the wisdom I have
received.  However, this appears to be the time to remember old desires to
see if they can be incorporated in new designs.

Offering a basic registering and finding GUID service (service?) would be
tricky, as I envision it anyway.  It would probably have to be an optional
registration; it would require some event catching for cut and paste moves;
and it would need some solid data integrity design and testing that are
definitely beyond my ken.  I realize something like this could be built as
needed from the Catalog, probably, but for it to be worthwhile the project
must be well-tested and even integral to Zope, I think.

On the bright side, it might encourage more fluid RDBMS/ZODB interaction (as
a RDBMS entry could refer to a ZODB entry with reasonable confidence), and
it might encourage less reliance on RDBMS for mid-complexity relational
problem domains (since ZODB relations could be built with more confidence,
more ease, and less memory usage).  On the dark side, it might be a
kludge--one that encourages opaque object references and subverts standard
ZODB path naming conventions.

-------------

If nothing else, here's another email from someone who cares enough to spend
a decent amount of time following along and thinking.  Thanks.

Gary