27.06.2001 01:12:27, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:

>> howdy,
>>
>> if I understand the spec correctly, multistatus responses are 
allowed
>> to group href's by status code in response to DELETE, MOVE & COPY
>> requests on collections, thus helping to keep the response compact.
>>
>> for example:
>>
>> DELETE /foo/ HTTP/1.1
>> ...
>>
>> --->
>>
>> ...
>> <D:multistatus>
>>   <D:response>
>>     <D:href>/foo/bar1</D:href>
>>     <D:href>/foo/bar2</D:href>
>>     <D:status>HTTP/1.1 423 Locked</D:href>
>>   </D:response>
>> </D:multistatus>
>>
>> this is currently not being done by the slide webdav-layer afaict.
>>
>> one way to make this nice and simple would be: the MacroException
>> class could store the exceptions categorized by their class, for
>> example in a hash table using the classname as key, and lists of 
the
>> actual exception instances as value. then there would be methods 
like
>>   Enumeration enumerateExceptionsOfClass(String classname)
>>   Enumeration enumerateExceptionClasses()
>>
>> so, does that seem reasonable or do you think the overhead would
>> outweigh the benefits ?
>
>I don't see why it would add some big overhead. That seems to be a 
good
>idea.

okay, I'll look into implementing and testing that...

on a related note, has anyone thought about a WebDAV-extension for 
JMeter (I'm not very much into that project, so I don't know if such 
an extension would be viable or even possible) or some other tool that 
would allow easy analysis of Slide's WebDAV-performance ?

>There's also the special case where there's only one entry in the 
nested
>exception, and the uri is the one on which the request was made : in 
that
>case, we should directly return the status code, instead of nesting 
it
>inside a 207.
>
>Remy

right.
maybe add an accessor for the first nested exception to MacroException 
?

-chris
________________________________________________________________
[EMAIL PROTECTED]


Reply via email to