Next message: Geoffrey M. Clemm: "Re: DAV:revision-resourcetype"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256872.007F3020.00@d54mta03.raleigh.ibm.com>
Date: Wed, 26 Jan 2000 18:06:41 -0500
Subject: Re: "stable" href's
See <jra> below...
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/26/2000
02:33:33 PM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: "stable" href's
From: jamsden@us.ibm.com
This feels a little like exposing server implementation details to
clients.
It's not a server implementation detail, but rather something the client
has to know in order to do its job. If it gets a stable URL, it can't
move it, and clients need to be designed accordingly. In particular,
a client can store these URL's in documents with a high degree of
confidence that they will continue to identify the same resource.
<jra>
Agreed
</jra>
Some servers may need to move these URLs around for one reason or
another.
I agree that they may be forced to do so, but with the understanding
that this will invalidate all cached copies of those URL's. What
is important is that *clients* cannot change those URL's, so that they
are only changed by some out-of-protocol administrative action.
<jra>
The server can't invalidate all the caches because it doesn't know what
caching some client might do. Stable URLs that aren't really stable, and
might change in server dependent ways don't sound that useful.
</jra>
So clients should only rely on the URL bindings they made and shouldn't
be
messing with server URLs.
If we don't define which are stable, how will a client know which ones
they can and should mess around with?
<jra>
I don't think clients should mess with any of them. And if we design the
protocol properly, they shouldn't have to. There may be cases for
non-versioning aware clients that these would enable some minimal
functionality. So we might need them, but in general the protocol should
avoid exposing them.
</jra>
I know we've said that there will be a stable URL
for each resource for versioning unaware clients,
These stable URL's are for versioning *aware* clients, so that they
can maintain reliable references to revisions, versioned resources, etc.
<jra>
But how reliable are they? Can we depend on them changing in some
interoperable way?
I don't think so.
</jra>
but I don't think those
URLs will be useful, especially to versioning unarare clients because
they
won't resemble anything meaningful.
A client is just a computer program, so when it is storing and
retrieving a URL, it doesn't really care whether it is meaningful,
but only that it continue to reference the intended resource.
<jra>
Such a client would have to display something to its eventual users to be
useful. If it is maintaining more human meaningful views, can't these be
bindings maintained by the server where they can be persisted and perhaps
reused by other clients?
</jra>
Cheers,
Geoff
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/20/2000
11:02:22 PM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: "stable" href's
After thinking for a while about Neil's question about whether a
MOVE can be applied to a revision, etc., I now believe that it would
be worthwhile for us to define which properties contain "stable"
URL's, i.e. URL's allocated by the server that cannot be modified
by a client with a MOVE request.
Unless anyone objects, I propose to make a pass through the protocol
identifying those properties which I believe identify stable hrefs.
The value to a client is that it can cache these names with the
guarantee that another client cannot MOVE them somewhere else. A
server can of course chose (or be forced) to break these bindings, but
there's nothing we can do about that.
Comments?
Cheers,
Geoff