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 Sun, 26 Oct 2003 21:52:52 GMT

Guido Casper wrote:
> 
> 
> The only change to your proposal to allow for both behaviours would be
> to not prohibit ambiguities.
> 
> Deal? :-)
> 

Yes, that was my bad. It had been a long day.

> >
> > This would handle for example the situation we currently have with
the
> > GIF- and JPEGSourceInspectors that actually deal with the same type
of
> > properties but define separate namespaces for them respectively. I'd
> > like to instead use the same property namespace for these:
> > http://apache.org/cocoon/inspector/image/1.0 .
> 
> Exactly. An example where dynamic behaviour would be beneficial.
> 

So, can I make this change then? Making the two use the same namespace I
mean.

> > ...

The thing is that, if you allow inspectors to handle arbitrary property
types, you need to communicate certain information between inspectors.

Consider a propfind for the image:width property on a source. Currently
there are two inspectors that deal with this property. However it
depends on the type of the source whether one, the other or neither will
be able to determine the property value. What if you tried to get this
property on a source of mime type text/xml? The manager will loop thru
the set of inspectors that assert they handle properties like that.
First comes GIFSourceInspector, then comes JPEGSourceInspector. Both
return a value of null since the mime type is beyond their epistemic
scope. Next in the list is an inspector that can in principal handle any
type because it just stores them as name-value pairs say. If this
inspector now chooses to query for the image:width property that would
certainly be undesirable behavior. 

So how to solve that?

My idea to guard against unexpected performance hits like this was to
require each inspector to know in advance what property types they deal
with. Making the requirement explicit by defining a method by which they
expose their respective property types. This would impact as you say the
flexibility in that the application must in advance know what properties
a client is going to use. And so we came up with a wildcard syntax that
would be tried if no exact match was available.

But I don't really like this. It complicates things too much.

So now I think, until we come up with something better, the best way for
the moment is to just let the inspectors decide for themselves like they
did before. If they decide to just try each and every property request
they get, then they must accept the impact this will have on the overall
performance of the system. The responsibility lies with them. I'll
provide an abstract base class that can configure what properties the
concrete inspector will deal with.

Cheers, Unico

Mime
View raw message