Re: Partial Puts

Larry Masinter writes:
>The nice thing about the separate "problem description" is that it lets
>you consider whether this is a real problem, serious, and worth making
>the protocol more complex.

I agree, and would like to encourage continued following of this practice.

> Is the "partial write capability" actually
>required ("needed") or just an optimization? Is it so important that
>interoperable clients cannot be written without it, or is it just a
>convenient optimization?

While it is possible to perform distributed authoring without having a
"write only the changes" capability, partial resource writing is critical
for allowing distributed authoring to scale up to large resource sizes.

The driving scenario is making updates to a resource which is 1MB long
(e.g., a large multi-sheet spreadsheet).  If only a few changes are made to
this resource (e.g., a couple of cells in the spreadsheet, under 10K), then
not only is it very wasteful to re-write the entire resource, but it will
take a long time to do so on most current network connections (decent
performance might be had on a local area network).

If people are to use WEBDAV facilities to make changes to large resources
without using more network resources than necessary, and without taking an
unecessarily long time to transmit their updates, a "write only the
changes" capability is needed.

>
>Just as range locking might be considered a case of locking a resource
>which happens to be a range of another resource, perhaps range
>(over)writing
>might be instead characterized as PUT-ing to a resource which just
>happens
>to be a part of another resource.
>
>That is, for the resource "MyDocument" you ask for the URL for the
>resource
>which corresponds to "Page1". The server gives you back a URL for Page1,
>which
>you PUT. The relationship between MyDocument and the Page1 resources is
>such
>that any update to Page1 of course updates the first page of MyDocument.
>
>This will work when the resource is stored as a file, as streams in an
>SGML database, or with separate files per page without the client having
>to be aware of the server's internal representation of resources.
>Perhaps
>there's a round trip in URL discovery, but it keeps the semantics of
>part/whole independent of the internal representation.

There seems to be a tradeoff here between making the server responsible for
understanding the structure of the resource (inherent in this proposal,
VTML, and PATCH) and making the client responsible for understanding the
structure (Goland proposal).  When the server understands the structure,
the client can send more structured updates (e.g., change this line, or
change this section).  When the client is responsible for understanding the
structure, the update seems to require a reduction to the least common
denominator structure across all media types, i.e. octet sequences.

I don't think we'll be able to reach consensus on this issue unless we
identify which tradeoff is best for DAV (and why).

- Jim

Received on Friday, 21 March 1997 19:22:30 UTC