RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
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:hazmat@objectrealms.net] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: Jean-Francois.Doyon@CCRS.NRCan.gc.ca; zope-dev@zope.org 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 Jean-Francois.Doyon@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.)
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
On Wed, 14 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
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 ?
I would say Ape is quite good at accepting data from non-Zope-aware tools, and I'd like to make it better. The fact that Ape stores the image dimensions separately from the image content is an implementation decision in the serializer. You could instead tell the serializer to detect image dimensions when loading the object. The detection is a relatively inexpensive operation. Shane
On Wed, 2004-04-14 at 10:44, Jean-Francois.Doyon@CCRS.NRCan.gc.ca 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:hazmat@objectrealms.net] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: Jean-Francois.Doyon@CCRS.NRCan.gc.ca; zope-dev@zope.org 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 Jean-Francois.Doyon@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.)
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
participants (3)
-
Jean-Francois.Doyon＠CCRS.NRCan.gc.ca -
Kapil Thangavelu -
Shane Hathaway