Next message: Tim Ellison OTT: "Re: DAV:revision-resourcetype"
Date: Thu, 27 Jan 2000 00:36:59 -0500
Message-Id: <10001270536.AA29155@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: "stable" href's
From: jamsden@us.ibm.com
<jra/> Some servers may need to move these URLs around for one reason or
another.
<gmc/> 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>
Poor choice of words on my part. By "invalidate all cached copies",
I meant "make all those cached copies invalid", i.e. they no longer
refer to what they are expected to refer to.
<gmc/> 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>
Most "href" XML elements not in the versioning protocol contain URL's
that can be messed with by the client. If we don't specifically state
in the versioning protocol that the versioning property href's are stable,
a client writer will have no way of knowing it. And *all* of our href
properties are stable, so we can't "avoid" exposing them (to clients).
Users of course won't see them.
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>
That's the whole point. We are defining them as *not* changing,
and therefore short of administrative intervention, a client *can*
count on them being stable, and perhaps even more importantly, a
server *can* refuse to MOVE them without surprising any client.
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>
These resources can be displayed in graphs, or annotated with their
labels, or any of a variety of means of conveying the information
of interest to the user. But a client cannot produce any of these
displays unless it has a reliable way of obtaining the resources
in question. And a server cannot do the caching it needs to do unless
it is allowed to refuse to change the names of those resources.
Cheers,
Geoff