Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

Jean-Francois.Doyon at CCRS.NRCan.gc.ca Jean-Francois.Doyon at CCRS.NRCan.gc.ca
Wed Apr 14 10:30:57 EDT 2004


Shane,

As Kapil already mentionned, svn's support for properties is quite flexible,
so that doesn't worry me too much.

I would imagine and administrator having the flexibility of choosing how
objects get translateds to files might be handy.

My initial, uneducated thoughts on the topic were simplistic, but then I'm a
big K.I.S.S. fan: simply pickle the entire object back and forth as one
entity.  This means for each object, there is one file on the fs.  The
benefit is greater simplicity ... the downside is that you couldn't check
those files out of subversion and interact with them.  I also have to
imagine the former is faster ?

But if usnig the latter, then I'd think that in SVN there would be only 1
file, written by a specific mapper for a specific content type, say image.
the data written to the file is such that if checked out, the file "works",
so I can open it in photoshop or something.

I however, would simply put everything else in properties, if that makes
sense at all. Zope properties, security information, and so on.  1 porperty,
1 piece of data. No need for reading/writing multi-line text.

The only thing I'm not so sure about is this "remainder" ... Though if it
really is a base64 encoded string, there's no reason not to put that in a
property as well.

The benefits I see:

- The filesystem reflects the object structure, no extra files lying around.
- a more consistent way to setup mappers/gateways: there's "data", and
there's everything else. Have a common/defined/smart way of handling
"everything else".
- with the use of the properties related svn funtions, we better leverage
SVN's features.
- possibly better performance/simpler code by not needing the whole multiple
file management and read/write of text files.  Heck the whole
AnnotatedFileSystem, thing could be dropped/replaced with a
PropertyFileSystem implementation of some kind maybe ??

What do you think ?

J.F.

-----Original Message-----
From: Shane Hathaway [mailto:shane at zope.com]
Sent: April 13, 2004 10:46 PM
To: Jean-Francois.Doyon at CCRS.NRCan.gc.ca
Cc: zope-dev at zope.org
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)


On Tue, 13 Apr 2004 Jean-Francois.Doyon at CCRS.NRCan.gc.ca wrote:

> Thanks for the extra tips, I'll check out those interfaces! I'm also
getting
> up to speed on the whole mapper concept, where the work regarding
properties
> handling seems to be ?

Ape supports both annotations and Zope properties.  Annotations are blocks
of multi-line text, while Zope properties are less constrained.  On the
filesystem, Ape stores many Zope properties together in a single
annotation called "properties".  Other annotations include object
classification, the remainder pickle (encoded in base 64), and security
information.

What are the expectations and limits of Subversion properties?  If they
are blocks of multi-line text, you can store the annotations as Subversion
properties.  If not, we'll still need a .properties file.  (Note that 
the name ".properties" is thus confusing.  Oops.)

> As for the seperation of code ... I now have a "subversion" directory as
a
> sibbling to "fs" ... I had to edit a couple of files outside that
directory,
> but still the seperation is nicer.
> 
> eventually I'd have to make it into a product, is that doable ?

Why not add your code to Ape?  I think it would be easier for both of us
to maintain that way.

Shane



More information about the Zope-Dev mailing list