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 ... J.F. -----Original Message----- From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 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.) > 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. -kapil _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )