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

[Shane Hathaway]

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

> 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 ?

If you store pickles, you can't merge, you can't store properties, in fact
you can't even store folders as directories or keep track of references
between objects.  At that point, you'd do much better to just use
FileStorage--KISS, after all.  Ape's real utility is in breaking objects
apart for storage.  If you don't need that, you don't need Ape.  But I
like to think it makes the job of breaking objects apart for storage
relatively simple.

> 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.

That's fine, although you'll need to distinguish Zope properties from 
other kinds of properties.  For example, if some object has a class_name 
Zope property, you'd be in trouble if the system mixed that up with the 
class_name key of the object classification.

> 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.

That's correct, it's always base64 encoded (with some comments.)

> The benefits I see:
> 
> - The filesystem reflects the object structure, no extra files lying around.

Definitely.

> - 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".

I would recommend you defer this for a while.  Lots of objects don't
easily fit this model.  For example, what is the "data" of a CMF tool?  
We can make plenty of progress on Subversion without thinking about 
changing the way mappers are defined.

> - with the use of the properties related svn funtions, we better leverage
> SVN's features.

Yup.

> - 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 ??

I'd guess there's no need for any such thing in Subversion.

I think your code might eventually share a lot of code with the fs
package, but if you'd like to start by making a clean break from the fs
package, by all means go ahead.

Shane