On Wed, 2004-04-14 at 10:44, [EMAIL PROTECTED] wrote: > 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.
agreed, its not something to worry about, and such naive clients are imo broken. > > 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 dreamweavnr 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 ? > well i think its also useful to think of svn as a sychronization point, like an rdbms. for other processes in other languages to interact with the content, like doing rich transforms/classification based on the content and storing as properties. using proper names for properties i think avoids the issue of dealing with client overlap, i would treat properties as though they were in xml namespaces, ie serialize dublincore author to dc:author, zope localroles -> zsecurity:localroles, etc. also its possible for zope to have total awareness of content changes done by external clients ( i depend on this functionality actually to reindex, get notification of deleted, apply wf to added content, etc.) but all of this happens at an application level not the zodb layer. > 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 ... > it is beyond scope, at min it requires a schema set for commonly defined properties which beyond the zope core properties are application specific. i wouldn't worry about to well into the future. -kapil > 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 )
