RE: Partial Puts

Why would we need to make a tradeoff? It looks to me like each solution
addresses a different scenario.

		Yaron


> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Friday, March 21, 1997 3:46 PM
> To:	w3c-dist-auth@w3.org; masinter@parc.xerox.com
> Subject:	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:30:25 UTC