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
