W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2003

Re: Distributing versions across servers

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 30 May 2003 10:54:43 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OFB695E997.9C361EC2-ON85256D36.004FF4FD-85256D36.0051EAF0@us.ibm.com>
ietf-dav-versioning-request@w3.org wrote on 05/30/2003 09:10:44 AM:

> 
> Hi Edgar,
> 
> thanks for answering. I will try to describe my problem from another
> direction.
> 
> What I was interested in was whether WebDAV supports a version history 
that
> comprises version resources stored on different servers.
> 
> I will try to explain it with a scenario, however, I will not use WebDAV
> terms, because when I do, I am somehow constrained to the WebDAV model 
and
> not able to say what I want to say.

I don't seen anything in your scenario below that you couldn't describe
using the WebDAV model.

> An abstract version (different from a
> VR!) is for me a persistent snapshot of a document at a point in time.

How is an "abstract version" any different from a VR?  A VR is a 
persistent
snapshot of a document at a point in time.

> Scenario: I create a document with some content and store it on server 
S1,
> resulting in version V1. This version is then copied to server S2,

Whether or not your server chose to make a copy of a version on another
server should be an implementation detail invisible to your client. 
Otherwise, your clients are unlikely to interoperate well with other 
servers
that make different choices about when or whether to make these copies.

Note that only the server can control this does not mean you
cannot describe it using the WebDAV model.

> manipulated there by someone else, resulting in version V2, however, 
stored
> at server S2. 

That's fine, but again, should not be something the client should try to
control (if you care whether that client interoperates with other 
servers).

> V1 and V2 constitute the document's version history.

That's correct.


> 
> Possible implementation with WebDAV (from my novice point of view): put
> document (resource) under version control at S1, resulting in VCR1, VH1, 
and
> VR1. Then copy VCR1 to S2 and put it under version control resulting in
> VCR2, VH2, and VR2. Reading Section 3.14 from the spec, VH2 is empty.

COPY creates a new resource ... that's not what you want.  What you do 
want
is to use the VERSION-CONTROL request to create VCR2 on S2, specifying VR1
as the version to initialize the new version-controlled resource.

> Now, there is no metadata structure that describes the connection 
between
> VCR1 and VCR2 (or VR1 and VR2, or VH1 and VH2), though from an 
application
> point of view they constitute a single version history. Thus I would 
have to
> implement a layer above WebDAV myself providing for the unified version
> history. At least that is how I interpreted the spec... Is this true? Or 
is
> there an alternative implementation with WebDAV that would preserve the
> connection of (abstract) versions V1 and V2?

If you use VERSION-CONTROL with VR1 as the argument to create VCR2, any 
new
version resources created by checking in VCR2 will be added as versions to
VH1.  Whether those versions are stored on S1 or S2 is up to your 
implementation,
but your implementation is certainly free to store the new versions on S2.

Cheers,
Geoff
 
> Regards, Martin
> 
> 
> |-----Ursprüngliche Nachricht-----
> |Von: ietf-dav-versioning-request@w3.org
> |[mailto:ietf-dav-versioning-request@w3.org] Im Auftrag von 
> |Edgar@EdgarSchwarz.de
> |Gesendet: Freitag, 30. Mai 2003 12:23
> |An: ietf-dav-versioning@w3.org
> |Cc: Edgar@EdgarSchwarz.de
> |Betreff: Re: Distributing versions across servers
> |
> |
> |
> |Hallo Martin,
> |
> |I'm not sure I completely understand what you want to achieve
> |but will give it a try.
> |
> |> Is it possible in WebDAV versioning that the version resources of a
> |> version history are distributed across mutliple servers?
> |The version resource is defined as the distinct URL of a
> |version. So if you do a checkin on a server I guess it makes 
> |sense for the server to create an URL for itself because it 
> |can't guarantee for any URL on another server to be available. 
> |Please give more details if this isn't what you wanted to know.
> |
> |> For example, is it possible to allocate three versions V1, V2
> |> (succeeding V1), and V3 (succeeding V2) on servers S1, S2, and S3 
> |> respectively?
> |What do you mean by 'allocate three versions' ?
> |Is 'version' a 'version resource' or a 'version-controlled resource' ?
> |
> |MfG, Edgar
> |
> |
> |-- 
> |edgar@edgarschwarz.de                  "http://www.edgarschwarz.de"
> |"http://www.edgar-schwarz.de/forum/oberon"    Running Active Oberon
> |Make it as simple as possible, but not simpler.     Albert Einstein
> |
> |
> 
> 
Received on Friday, 30 May 2003 10:55:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:44 GMT