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]