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