Next message: Geoffrey M. Clemm: "Re: comments on deltav-08.2"
Date: Mon, 25 Sep 2000 08:36:49 -0400 (EDT)
Message-Id: <200009251236.IAA24419@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: DAV:version-set
From: Ron Jacobs <rjacobs@gforce.com>
I think this topic has been discussed before, but for me the issue is still
alive as of the 08.2 spec.
Is the DAV:version-set property (section 14.2.1) required to be implemented
by a server?
Everything in advanced versioning is optional, so, no, the DAV:version-set
property is not required (in fact, explicitly representing the version history
as a separate resource is optional).
I am designing a versioning server that routinely may have thousands (or
perhaps hundreds of thousands) of versions of a resource. (Yep, you read
that correctly :)
Do I have to be able to return that many version URLs? I would be happier
relying upon predecessor and successor properties as well as the
DAV:version-tree-report.
That's fine. You could for example only implement the DAV:initial-version
property of the history resource. Note that the DAV:version-tree-report
doesn't solve your problem, since it would return all hundreds of thousands
of versions.
On a very related topic, hasn't there been discussion regarding whether (and
how) a server may limit the size of its response bodies, especially for
reports? I can't find any mention of this in the current draft. How has the
issue been resolved?
This is a general WebDAV problem, but I am not aware of a proposal for how
to address the problem (although certainly one could imagince a variety of
approaches). The "Depth" header addresses a related problem, but wouldn't
apply to the general response body size problem.
Wouldn't the Range request header and Content-Range entity header be useful
for breaking up large responses into multiple request/response pairs? How
does a REPORT with a potentially huge response differ from a GET of a
potentially huge document?
Is there anything that would preclude such an implementation?
The problem with Content-Range is that is just cuts off at some byte increment,
which wouldn't make for a very useful XML fragment. So you probably need
some kind of structured subset mechanism (which then gets trickier).
Cheers,
Geoff