cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: repository block (was Re: [RT] Source extensions)
Date Fri, 24 Oct 2003 11:32:27 GMT
 

> 
> -----Original Message-----
> From: Guido Casper [mailto:gcasper@s-und-n.de] 
> Sent: vrijdag 24 oktober 2003 12:41
> To: dev@cocoon.apache.org
> 
> Unico Hommes <Unico@hippo.nl> 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
> 
> 

Mime
View raw message