Next message: Tim Ellison/OTT/OTI: "Versioned Collections"
To: ietf-dav-versioning@w3.org
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Message-ID: <OFF4398F8D.A924D142-ON852568CF.0009B570@ott.oti.com>
Date: Thu, 27 Apr 2000 22:48:35 -0400
Subject: DAV:revision-set
10.3.2 DAV:revision-set
I'm hoping that this is a typo<g>
<geoff/>
Nope ... most implementations will compute this property rather than store
it as flat text (:-).
<tim/>
Even so, imagine the length of the response that the server will have to
construct and the client will have to swallow. Without any throttling I
wouldn't want to implement this as a server.
If it really contains all the stable URLs for ALL revisions that it
selects
then that could be potentially a very large number (thousands).
<geoff/>
Yup. This means that only small workspaces should ever be asked for their
DAV:revisions.
<tim/>
...but a client has no way of knowing that it is a small workspace without
asking the question -- by which point the writing is on the wall for the
server/client.
Imagine
merging a baseline and getting all the members of the baseline in this
set.
Consider re-writing this to be the stable URLs of the default revisions
set
in the workspace. We would then say (elsewhere) that when a clients
sets a
default revision that is a container (i.e., baseline, activity, etc.)
the
effect on target selection is as though each member of the container
had
been set individually in the workspace (though servers are not expected
to
implement it that way).
<geoff>
This doesn't work well in the context of merging, since parts of each of
the various entities merged in will be selected.
But for large workspaces, I agree that the baselines and activities that
have gone into the workspace are what the client is more likely to ask
for, but that information is available in the DAV:predecessor-set and
DAV:activity-set properties of a workspace.
</geoff>
<tim/>
Footnote: checkin your workspaces frequently ;-)
Tim