The property schema thing is a good point, though I'm not sure we could ever
do anything about it, not with the purpose to help "naive gui" clients work
better with the repository.

By nature the object structure (Class instance) is not fixed, so the
amount/name/data of properties could vary arbitrarily.  This is after all
the major benefit of an OODBMS.

Fact is if one wanted a client to interact with a svn repository that stores
zope objects, it would need to be fairly specifically designed for it ...
How would a client (Say dreamweaver with a subversion plug-in) know that
when editing an image, the x and y size properties need to be updated ? What
if someone monkey patches the image type to add some other
property/attribute ?

All we could hope to do is find a consistent and predictable way to handle
properties, so that clients would know at the very least how to read/write
them, but not necessarily know which one does what.  I suppose there's
possible ways around that actually, by providing some way to describe
properties and what they do and so on ... but that's beyond the scope of
what I'm trying to do I think ...


-----Original Message-----
From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 6:51 AM
To: Shane Hathaway
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)

On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
> On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:
> > Thanks for the extra tips, I'll check out those interfaces! I'm also
> > up to speed on the whole mapper concept, where the work regarding
> > 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.)

svn supports aribtrary property values. ie you can store binary
(remainder pickles, object classification, etc.) of arbitrary size on
them. there is some question of how well some naive gui client will do
when trying to list such properties, as there is currently no notion of
metaproperties/property schema beyond the property namespace for
introspection of a property.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to