Next message: Geoffrey M. Clemm: "Re: working resource DAV:merge-state property?"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568C1.0063122A.00@d54mta03.raleigh.ibm.com>
Date: Fri, 14 Apr 2000 14:02:06 -0400
Subject: Re: working resource DAV:merge-state property?
Its not so much that adding the property adds any particular complexity,
its the implications of having these properties, their exact meaning, and
what it means to support them or not by different servers. For example, in
the cases below:
- empty: and empty body would never be correct unless the target was
already empty. The target of the merge would be a better initial candidate
as it atleast has some of the merged contents.
- something: to get interoperability, will we be forced to say what gets
done for each resource type? I don't think we want to get into this, but
its the kind of issue that can come up.
- done: again, the meaning of 'done' may depend on the resource types, the
structure and meaning of their contents, and what it means to merge. There
will be cases where this is easy, and others where it is impossible. I
think the result of a merge always has a quality component that I'm having
trouble fitting in with a communication protocol.
Other than not wanting to address these questions now, or delay the spec in
order to resolve them, I'm all for it.
|------------------------+------------------------>
| | "Geoffrey M. Clemm" |
| | <geoffrey.clemm@ratio|
| | nal.com> |
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 04/14/2000 11:02 AM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| Subject: |
| Re: working resource |
| DAV:merge-state |
| property? |
>------------------------|
<geoff> With the MERGE method, a new working resource is created
with multiple predecessors. In some cases, the server will give the
new working resource an empty body; in other cases, the server will
support an automatic merge capability and can populate the working
resource with some initial text; and in other cases the initial text
is suitable for checking-in, after review by the user.It is probably
useful/important for the server to indicate which of these states
the working resource is in, e.g. DAV:initial; DAV:intermediate;
DAV:final </geoff>
From: jamsden@us.ibm.com
These are good and sensible arguments for additional merge support
in the server. I agree with all of them. However, in the interest
of simplification and achieving agreement on the critical
versioning semantics and protocol, should we defer this
discussion to a future enhancement? I'm just concerned that the
complexity of dealing with merging in a generic way without user
interaction will deflect our attention from more fundamental
issues. I'd be happy to address this after we get workspaces,
activities, and configurations nailed down, let alone core
versioning.
Since the proposal is just to add a single property to the working
resource (DAV:merge-state), and since the semantics of this property
are very simple (empty, something, done), I believe that the
complexity this adds to the protocol is significantly outweighed by the
benefit.
Cheers,
Geoff