Re: configurations and snapshots
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Wed, 07 Apr 1999 10:20:44 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Apr07.101700.1250.1137474@otismtp.ott.oti.com>
Date: Wed, 07 Apr 1999 10:20:44 -0400
Subject: RE: configurations and snapshots
> From: jamsden [mailto:jamsden@us.ibm.com]
> > From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
>
> > - Can I spec an RSR to use the "latest" revision of a
> configuration?
>
> The point of configurations is predictability. A user puts a
> configuration
> in their workspace RSR and expects to see a consistent set of
> revisions
> based on some release. If configuration@latest were allowed,
> the workspace
> could change without the user doing anything. This would be
> unexpected in
> most cases and starts looking like mutable configurations.
I actually don't buy this. The point of *a* configuration is that its
contents are predictable. The point of using configs in RSRs is to have
a short hand way of talking about a group of resources. By your
argument, using the label "latest" in the RSRs is unpredictable and so
not good.
Anywya, I won't push on this too hard since I agree with Geoff's argument
there may well be significant implementation overheads in supporting
this. When you checkin a config to such a server, it would likely have
to check and update all the workspace RSR implementations using that
config (due to caching).
I argue for this because I have experienced the pain of continually
trying to keep revision-specific things in sync.
Jeff