Next message: Greg Stein: "Re: workspace stuff (was: Re: move/copy/delete/etc in a change set)"
Date: Thu, 10 Aug 2000 23:44:50 -0400 (EDT)
Message-Id: <200008110344.XAA13155@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: workspace stuff (was: Re: move/copy/delete/etc in a change set)
From: Greg Stein <gstein@lyra.org>
The Workspace header means that the /foo/bar.html is not necessarily
unique. The URI is further differentiated by another header (thus leading
into the whole "Vary" thing). For a multiple-use server such as Apache, the
header means that stuff can just "show up" at URLs that weren't
administratively created.
Yes, that is why I expect some servers that do support workspaces
will chose to not support the Workspace header.
[ for the record, I want multiple checkouts, but only for short periods of
time -- the client will do MKACTIVITY, CHECKOUT, MERGE <activity>; if a
couple clients are hitting the server at the same time, there is a point
between CHECKOUT and MERGE where they could both have it out at the same
time; I want this allowed in case the first client aborts before the final
MERGE step; I don't want the second guy prematurely locked out ]
Sounds reasonable. Although those "short periods of time" can end up being
rather long ... (:-).
> I find that a problem since I'd want the WS to mirror the
> live URL space;
>
> Why is that a problem? If you always use a Workspace header,
> it will look like you've got the live URL space at your disposal.
Euh. Nope. Section 11.1 is the issue I'm referring to. It states that any
request with a Workspace header must fail if there is a corresponding
internal member.
Wait, wait!! That clause was supposed to be deleted. We decided to
kill it because of the reasons you describe below. No wonder you
don't like workspaces!
In other words, I have /project/index.html on my server. I can't just shift
that into a workspace and use it /project/index.html. It must be
differentiated somehow, say /ws/project/index.html. If it must be
differentiated, then why bother with the Workspace header? If I can say
/ws/..., then I can say /ws/gstein/3/... just as easily.
Exactly right. Which is why that clause (albeit a well intentioned effort
to make sure you didn't hide versioning metadata :-) was bogus and wrong.
This is the "feature" of workspaces that I disagree with. I'm a late comer
to this, so I'm assuming there is a valid reason for the design. That's why
I said "just me" doesn't like it, and I'm not going to argue against its
inclusion.
Well, I'm glad you raised the issue, since this is a bug, not a feature.
In general, if something you see doesn't look right, please raise it as
an issue (especially if you're going to be doing any implementing!).
Even if it is there for a good reason, if that reason is not clear from
the spec, that's a bug that should be fixed by improving the explanation.
> Note that a workspace does not have to be on the same host as the
> versioned resources or as other workspaces, so mounting a workspace
> at "/" of some host is totally reasonable.
We're back to the hacky nature of this stuff :-) A whole separate host name
just to deal with the Workspace header? hehe. Really, listen to what you're
saying :-)
Hmmm. I didn't mean to say anything strange (:-). Putting a workspace at
"/" just means that you are guaranteed "checkout in place" behavior for all
version selectors on that host (since every version selector on that host
will be a member of a workspace). This doesn't really have anything to
do with a Workspace header (at least, I don't think it is related).
In any case, I'll delete that offending section of 11.1.
Cheers,
Geoff