> > -----Original Message----- > From: Guido Casper [mailto:[EMAIL PROTECTED] > Sent: vrijdag 24 oktober 2003 12:41 > To: [EMAIL PROTECTED] > > Unico Hommes <[EMAIL PROTECTED]> wrote: > >>> A related change I need to make is described here: > >>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699 this will > >>> not only improve performance of querying for a specific > property but > >>> is prerequisite for setting properties via the > >>> SourceDescriptionManager. > >> > >> I'm not sure. > >> What exactly is the meaning of the returned Strings? > >> > > > > They identify a property type: namespace + "#" + propname. The > > previous implementation of the inspector manager's > > getSourceProperty() method was looping over all registered > inspectors > > until it found the property it was looking for. > > > > In order to make this process more efficient the manager needs to > > register the individual inspectors to handle specific > properties. The > > getExposedPropertyTypes() method enables this. > > > >> Is it all properties "supported" by a particular SourceInspector > >> implementation? > > > > Yes. > > > >> What if it supports any within a particular namespace? > >> What if it support any within any namespace? > >> > >> How would that be represented? > > > > Nothing in place for that yet, but we could add it easily. > Just need a > > convention. What about using wildcards for this: > > > > *#myprop > > myns#* > > *#* > > > > This way a simple jdbc descriptor that stores properties as > key value > > pairs in a database can assert it is general enough to handle any > > property. The manager then looks for an inspector in order > from most > > specific (exact match) to least specific (*#*). > > The way the manager caches the values for lookups looks to me > like sacrifying a lot of flexibility.
Well, I would say not a *lot* but a *little*. But perhaps we could make it better. > I don't really see a > way to avoid the looping (Is it really that costly?). > Yes, it can be. This is the one of the reasons WebDAV specifies a way to PROPFIND specific properties. Consider a PROPFIND call on a collection with depth 1. The collection contains 20 children. The propfind queries for the property "myns:myprop". The following inspectors are registered with the manager: simple jdbc inspector, webdav inspector, xpath inspector. In the case that you are looping over the inspectors you could find yourself in a situation where it takes 20 database calls + 20 webdav calls + 20 xpath traversals just to find out that the property doesn't exist on the children of the collection. > Caching the set of supported properties is ok, but it should > be a concern of the individual SourceInspector implementation > IMO, since it could change at runtime (think access control > for instance). That might also be a reason for the above > lookup mechanism to break. > Why couldn't this use case be implemented by declaring an inspector that handles aclns#* properties? Anyway, I see your point of caching the set of supported properties with the individual SourceInspectors and I see why that would solve changes at runtime. I hadn't thought about that case yet. I'd be +1 for changing it that way. B.t.w. I noticed you hadn't moved SourcePropsWritingTransformer in webdav block to repository yet. Any particular reason why? Should I move it? -- Unico > Guido > >
