Re: Re2: what's doable in Web version control

Fabio Vitali (vitali@cis.njit.edu)
Tue, 11 Jun 1996 11:53:50 -0500


>I'm re-reading the VTML document, but I don't think what I intended
>for "multipart/update" matches what VTML does.
>
>What I *intended* was basically just a replacement for (one or more)
>PUT operations, which contained a set of headers that were appropriate
>for an update. VTML seems like it's much more a representation -- in a
>single file -- of a versioned resource.

No. Or rather, er, well, *yes*, but not only.

VTML was designed so as to provide a representation in which the content of
all versions of a resource can be represented as a single stream, *as well
as* a set of disjoint streams (containing deltas), *as well as* any mixed
combination of the two that makes sense (thereby requesting that if a
version is externalized, then all its derived versions must be external as
well, and that merging versions must have all merged resources
internalized). Using your words, it is indeed a *representation* (i.e. a
data format, I assume), but it is not restricted to a single stream.

>I'm sorry for waving about a name ("multipart/update") without giving
>a binding for it, since it leaves too much to the imagination.

Indeed. What's not clear to me is the actual reason for a "multipart" MIME
type.
This means, what do you exactly need to send in more than one version at a
time for? I see two possible explanations:

1) you want to send in updates for different resources (e.g. a file AND its
ancillary images, all modified in the meantime), and want a single commit
for all of them -- and this is, I understand, *evil*.

2) you want to send in several updates for the same resource: e.g. I check
out a file for the weekend on my laptop, create locally several versions --
friday night, saturday afternoon just before the party, and sunday evening
because I'm bored -- and check them back in first thing monday morning as a
single connection, with the different parts representing the different
versions that were created locally. -- This was considered an interesting
option for VTML, and one of the main reasons for external deltas.

In the second case, provided that VTML deltas may be the body of each part
of a multipart/update transmission, I think I am fine with the proposal.

Or did you have something else in mind?

Fabio