cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: repository block (was Re: [RT] Source extensions)
Date Mon, 27 Oct 2003 10:12:48 GMT
Unico Hommes <Unico@hippo.nl> wrote:
> 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.

No no, you were the one opening my (and hopefully other's) eyes how
powerful all this is :-)

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

+1 from me

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

One can blame the one trying to read image:width on a XML resource :-)

I can see the problem of several inspectors not checking the namespace.
Maybe the implementor should make sure there is no more than 1 of them
(but then again you have to ensure the correct sequence of calling (the
same applies for setting props)). Maybe another mechanism for ensuring
more robustness is needed. Hmm ... keeping on thinking about that.

Hope I can work on it for my next project (don't know yet) and gather
some more experiences.

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

Thanks a lot for your work.

Guido


Mime
View raw message