Re: WebDAV DTD

>The benefit is that, if the client sees the status first, and knows
>the operation failed, then it can avoid buffering the contents of
>the prop element.  With an existing server, the only problem
>would be that it would have to buffer all the time.

Exactly -- I can see it now, some bright spark chooses to store a hunk of 
video in a property ... or a long live property ...

>Uh...but now I'm wondering whether this actually makes sense.
>Is there any case where the operation failed but you get a prop
>with an actual value in it?

The only cases that seem to make sense to me are those where the server 
manages to retrieve partial content before the error occurs.  Presumably 
these would result in error code (500 Internal Server Error).


Tim
 ----------
>From: John Stracke
>To: w3c-dist-auth
>Subject: Re: WebDAV DTD
>Date: Tuesday, October 12, 1999 4:32PM
>
><<File Attachment: HEADER.TXT>>
>Jim Whitehead wrote:
>
>> > One rule in the DTD states:
>> >     <!ELEMENT propstat (prop, status, responsedescription?) >
>> >
>> > I suggest that this is modified to read
>> >     <!ELEMENT propstat (status, responsedescription?, prop) >
>> >
>> > so that streaming clients can retrieve the status of a property
>> > before they retireve the property itself , and thereby know whether the
>> data
>> > is valid or not.  In the current rule, such a client is required to 
read
>> the prop data
>> > in its entirety, possibly to discover that the data is invalid only 
after
>> > the fact.
>>
>> That said, I don't find this to be a particularly compelling argument. 
 In
>> general you'll need to parse the entire propstat block anyway just so you
>> can find its end.  And, clients will need to be able to accept either
>> ordering, since there are existing servers that send the data as prop,
>> status, responsedescription. So, I'm not sure what benefit this change 
gains
>> you.
>
>The benefit is that, if the client sees the status first, and knows the
>operation failed, then it can avoid buffering the contents of the prop
>element.  With an existing server, the only problem would be that it would
>have
>to buffer all the time.
>
>Uh...but now I'm wondering whether this actually makes sense.  Is there any
>case where the operation failed but you get a prop with an actual value in 
it?
>
>--
>/==============================================================\
>|John Stracke    | http://www.ecal.com |My opinions are my own.|
>|Chief Scientist |=============================================|
>|eCal Corp.      |But this one goes to 11x.                    |
>|francis@ecal.com|                                             |
>\==============================================================/
>
>
>
>

Received on Tuesday, 12 October 1999 16:59:52 UTC