Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:57:47 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:57:47 -0800
Message-ID: <003501be7ca3$d315fe60$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: Bruce Cragun [mailto:BCragun.ORM2-1.OREM2@gw.novell.com]
Sent: Friday, February 19, 1999 9:30 AM
To: ckaler@microsoft.com; jamsden@us.ibm.com
Cc: gclemm@atria.com; dgd@cs.bu.edu; ejw@ics.uci.edu;
bradley_sergeant@intersolv.com; sridhar.iyengar@mv.unisys.com
Subject: RE: Version issues
Chris and I are definitely on the same page.
[the following paragraph is from Chris:]
In the example I just gave, the client has to do extra work just to get
a specific version. This seems like an unnecessary burden. Likewise,
forcing a level 1 server to support workspaces will require putting a
new abstraction on top of the servers to support a client scenario that
is clearly not interesting to them. I say clearly
because if it were important, they would support it with today's
products.
I wholeheartedly agree.
>>> Chris Kaler <ckaler@microsoft.com> 02/19/99 12:56AM >>>
Comments below...
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, February 18, 1999 7:28 PM
To: Chris Kaler
Cc: jamsden@us.ibm.com; gclemm@atria.com;
ejw@ics.uci.edu; dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; Chris Kaler;
bradley_sergeant@intersolv.com;
ABabich@filenet.com
Subject: RE: Version issues
Chris,
Your solution is too single-resource, single-user
oriented
and won't scale
to multiple users accessing multiple revisions of
multiple
versioned
resources over some span of time. There MUST be some way
for
each user to
have his own "revision space", a way to specify what
revisions of versioned
resources he wants to see at some point in time. This
selection must be
able to vary over resources, user agents, and time.
Level 1
users will have
to have this capability. It is fundamental and minimal
for a
versioning
system. Without it, multiple versions have extremely
limited
use.
[CK] I think this is where Bruce and I disagree with
you.
We have systems
today that do this today and don't support the
notion of per-user views.
Everyone shares the same view. I understand
your
scalability concerns,
but forcing clients to adopt a new paradigm, is
an
unpleasant thought.
I'd also argue that Novell's system scales
pretty
well without this today.
This can't be done with simple defaults because if
anyone
changes the
default revision for a versioned resource, it changes it
for
everyone.
There's no way for some other user to see a different
default, or for the
same user to access a different set of defaults at some
other time without
changing a whole bunch of labels. Pity the user that
needs
to go back to
revision 1 of a whole bunch of resources.
[CK] Typically, when a non-tip version is made the
default,
the desired
behavior is for everyone to get the new default.
I
think a key disconnect
here is that I believe there is a way to request
a
specific revision of a
document at any point in time irrespective of a
workspace. This is what
tools do today. If you "get" a document, you
are
given the default version.
You can view the history and select a specific
version. If you do, then
you are given the specified version. I think
an
implied "default workspace"
if fine for Level 1, but you must be able to
"override" this and get a specific
version (or check it out) at any time. I don't
believe that creating a new
workspace is a viable approach here.
Workspaces solve this problem by allowing users to
create a
resource
containing a revision selection rule that specifies
what
revisions they
want to see. These workspaces can be shared, copied,
locked,
saved and
reused at some other time, etc. The are simple,
effective,
and provide a
scaleable mechanism that is appropriate for level 1 and
2.
Parallel
activities and configurations fit right in.
[CK] But if I want version 6 of foo.htm, it seems like
a
burden to have the
client create a workspace, set the RSR on the
workspace to include
version 6 of foo.htm, and then GET foo.htm from
the
new workspace,
and then delete the workspace. Why can't the
client
just say
"GET version 6 of foo.htm" in a single request.
In all these discussions, I have not seen one scenario
that
indicates
workspaces are "too hard" for level 1 clients or
servers. It
is not
sufficient to just say level 1 servers would never...
We
need to back this
up with specific scenarios that expose deficiencies or
complexities. I do
not feel that having workspaces and setting labels in
revision selection
rules are hard. What's hard is trying to come up with
ways
of avoiding
them. I need to see the justification. Again, what do
workspaces do that
are inappropriate for level 1? What functionality is
missing
if they are
included? Specific scenarios, not speculation.
[CK] In the example I just gave, the client has to do
extra
work just to get
a specific version. This seems like an
unnecessary
burden. Likewise,
forcing a level 1 server to support workspaces
will
require putting a
new abstraction on top of the servers to support
a
client scenario that
is clearly not interesting to them. I say
clearly
because if it were
important, they would support it with today's
products.
Now if you are saying that level 1 servers just
support the notion of
A default workspace, then I don't think there is
a
large burden on the
servers. However, I don't understand how
clients
get a specific version
without changing the default for everyone
(which
clearly doesn't scale).
As well, in my previous mail, I gave an example
where if I want to set
version 6 of foo.htm to be the default and I
must do
this via a label, then
the client must do a PROPFIND followed by a
PROPPATCH. If I am
setting several defaults, doubling my server
communication will start
to get costly. The other example why I believe
labels are the wrong
way to set default revisions is the shared
namespace
example. In
this case you are setting properties on "both
ends"
of the reference.
I think this is very confusing and could cause
additional server complexity.
However, I admit that this is a very subjective
observation :-)
are just saying
Chris Kaler <ckaler@microsoft.com> on 02/18/99 04:08:35
PM
To: Jim Amsden/Raleigh/IBM
cc:
Subject: RE: Version issues
I understand your argument that I don't need to pull the
RSR
if I am
willing
to set a label. However, unless you define a
"standard"
label that means
make this the default, you force the client to expose
the
notion of an RSR
because they will have to pick a label to use. So let's
say
we define
"Default" as the label to use. Level 1 servers have a
notion of a default
workspace whose RSR is set to "Label='Default'". Level
1
clients never
have
to know about workspaces or RSRs. So set a default
revision, they set the
label on that revision to be "Default". I think this
is
viable, but has a
few problems:
1) When I use a direct reference to create a "share" in
the
namespace,
I may (will) want to have different default revisions
for
/a/foo and
/b/foo. Using PROPPATCH to do this could be complex
for
servers. I
think that a method allows the easiest way for server
and
doesn't
make the client any better or worse.
2) Since a revision can have multiple labels associated
with
it, to make
it the default I must PROPFIND to get the current
labels,
add the new
label, and PROPPATCH to change it. To me, a help
method
would be
very useful here.
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, February 18, 1999 9:28 AM
To: Chris Kaler
Subject: RE: Version issues
Chris,
See below...
Chris Kaler <ckaler@microsoft.com> on 02/18/99 11:58:45
AM
To: Jim Amsden/Raleigh/IBM, Bruce Cragun
<BCragun.ORM2-1.OREM2@GW.Novell.com>
cc: gclemm@atria.com, ejw@ics.uci.edu, dgd@cs.bu.edu,
Cragun.Bruce@GW.Novell.com,
sridhar.iyengar@mv.unisys.com,
bradley_sergeant@intersolv.com,
ABabich@filenet.com
Subject: RE: Version issues
So I guess I object to having to pull the entire RSR
(which
could get
large), just to change the default revision of a single
resource, even in
Level 2. It is inefficient and has scaling problems.
I
don't think it is
unreasonable to have a "helper" method for this.
<jra>
There's no need to touch the RSR to set the default
revision. Just label
the revision with a label that's in the RSR, likely a
label
that has been
used on revisions of other related versioned resources.
There seems to be
some consfusion that an RSR has to contain the revision
id
of every
resource resolved by the workspace. This is not the
case.
The RSR only
needs to contain a label. Any revision of versioned
resources having that
label will be selected.
</jra>
If we agree on that (which I don't think we do), then
Level
1 is easy,
because servers only need to implement the help and a
"default workspace"
is
assumed. When they become Level 2 servers, there is a
natural path.
I don't think we can force workspaces onto Level 1
servers
-- Bruce's
comments about it not being necessary are true. If I
want
to have a DMS
which versions automatically but, by default, only
allows me
to get the tip
version, then all this stuff is overhead to me and I
don't
want to build
it.
For systems like this, I use the versioning as a safety
mechanism and I
will
go to the server to restore older versions.
<jra>
It makes no sense to provide a means of creating
multiple
revisions, and
then assume no-one will use the old revisions.
Workspaces in
level 1 will
provide a simple, poor-man's configuration. They allow
different users to
see different sets of revisions at different times.
This
seems fundamental
to me, and I think the usefulness of level 1 would be
severly compromised
with out it.
</jra>
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, February 18, 1999 8:01 AM
To: Bruce Cragun
Cc: jamsden@us.ibm.com; gclemm@atria.com;
ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@GW.Novell.com;
sridhar.iyengar@mv.unisys.com; Chris Kaler;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues
Comments below in <jra> tags.
"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on
02/18/99 10:15:43 AM
To: Jim Amsden/Raleigh/IBM
cc:
Subject: RE: Version issues
Nobody is claiming workspaces are too difficult, and I'm
not
against
being required to do them. I'm against being required
to do
them if
they aren't necessary. Every "little" thing we require
in
Level 1 is
one more deterrent in getting people to support
versioning.
Still, I
don't want to make too big an issue of this since we
have
bigger issues
with the standard still to tackle.
<jra>
Something is necessary to resolve a URL to a versioned
resource to a
specific revision. Let's just not have two things, one
for
each level. At
the same time, I would like to avoid special cases that
we
do for level 1
that appear to be simpler, but don't scale and aren't
applicable to level
2.
</jra>
What is my default workspace going to do, though, when I
ask
for a
versioned resource? I believe you have indicated a
preference that the
default workspace give me either a) the checked-out
revision, or b) the
latest revision if none are checked out. That would be
okay, but why
would I need a workspace to accomplish this? And what
if
more than one
revision is checked out?
<jra>
You need a workspace because this is only one case that
is a
reasonable
default. Another is checkedout, R1, and latest. That is
get
anything I have
checked out, or get a revision labeled R1 for release 1,
or
get latest if
the versioned resource doesn't have a revision labeled
R1.
This is an
extremely simple and common case for versioning, and a
workspace does it
just fine. There might be other mechanisms that would
work
too, but they
would probably end up looking a lot like workspaces.
We need to think a little more about having two
revisions of
the same
versioned resource checked out at the same time.
Currently,
this would
require separate activities to disambiguate the working
resource. Rember,
checkouts in WebDAV aren't extracting a resource to the
local file system
where the user can specify a local file name. The
resources
are checked out
on the web, are accessed using the same URL that was
used
before they were
checked out (to provide uniform access), and can be
accessed
by many users
at the same time subject to locks (on the working
resource
that is). This
is a different paradigm, one that has different
capabilities, some better,
some less flexible.
</jra>
You also say workspaces are not about creating sets. I
understand the
revision selection rule part of workspaces, but are
workspaces 1-to-1
with revisions/versioned resources? I have understood
that
a workspace
referred to 1..n resources, with a selection rule for
each.
Looking
back at the definition in the Goals document, I see it
doesn't indicate
1..n. Hmmmm.
<jra>
A repository can contain many workspaces, one of which
is
the default
workspace. Users create and use workspaces to meet
their
needs. The default
workspace is used if one isn't specified.
A workspace doesn't contain any resources, versioned or
otherwise. It isn't
a collection. A workspace does specify a revision
selection
rule, one rule,
having many entries. Each entry can be one of:
"checkedout",
the URL of the
current activity, the URL of a merge activity (maybe
more
than one, not
sure yet), a label, a configuration, or "latest". The
URL of
an arbitrary
versioned resource is resolved in the context of a
workspace
to a
particular revision. This is done by searching through
the
entries in the
revision selection rule in order looking for a match.
The
first revision
that matches is the one selected. If there is no
matching
revision, then a
resource not found status is returned.
So a workspace maps or resolves many versioned resources
to
a single
revision for each versioned resource. There is only one
revision selection
rule in a workspace, and it is applied to all versioned
resources resolved
in the context of that workspace. That rule may have
multiple entries that
specify the matching order.
</jra>
So what, then, is the difference between the workspace
and
the
selection rule other than the fact that the workspace
*contains* a
selection rule?
<jra>
That's all a workspace is, a resource that contains a
revision selection
rule. One refers to a workspace with a URL, just like
any
other resource.
We may want to define a mime type for activities and
workspaces. A
workspace is a resource so its extensible. The revision
selection rule is
its contents.
</jra>
>>> <jamsden@us.ibm.com> 02/18/99 06:06AM >>>
Bruce,
Unfortunately, its not that simple. If you have
multiple
revisions,
each
with a label, and you allow either non-versioning
clients
and/or
versioning
clients to specify URLs without specifying a label,
something must
happen.
A revision has to be selected. What I'm trying to avoid
is
having
different
mechanisms for level 1 and level 2; default revisions,
and
workspaces.
These two mechanisms conflict if both were implemented
in
level 2. In
addition, I think default revisions don't scale and
would be
harder
for
users to use and servers to implement than simple
workspaces. Let's try
to
understand what the issues are with workspaces in level
1.
Why would
level
1 servers not want to implement them? What would they
find
too hard?
Workspaces aren't about defining sets of resources,
they're
about
resolving
URLs referencing a versioned resource to a particular
revision. Level
1
servers have to do this somehow. I think workspaces are
the
simplest
way
for both clients and servers. They also provide some
additional
flexibility
for free, and would be consistent across levels. Sounds
like
a win-win
situation.
"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on
02/17/99
07:12:40 PM
To: Jim Amsden/Raleigh/IBM
cc: w3c-dist-auth@w3.org
Subject: RE: Version issues
Okay, I see our disconnect. You are assuming that, even
in
Level 1,
we
want some method of creating / identifying a logical
*set*
of
resources,
such as all revisions that made up a particular
milestone or
release.
In the DMS world there is no such grouping ability;
every
file is on
its
own. In the web site arena, however, I can see some
value
in this
grouping concept.
A simple versioning client and/or server, I believe,
will
not
generally
implement workspaces if given a choice. If that is
true,
then I would
vote to leave workspaces in Level 2. If with my
particular
product I
want only basic versioning, but the ability to create
sets
(workspaces)
is important, then I can implement Level 1 versioning
and
add
workspaces
without the rest of Level 2. Now my client and my
server
can take
advantage of the ability to use workspaces, but other
peoples' Level 1
clients can still make use of my server. Workspaces are
a
useful
"utility" not a required piece of functionality.
So I vote workspaces remain in Level 2.
>>> <jamsden@us.ibm.com> 02/17/99 01:44PM >>>
Bruce,
I'm sorry to hear you weren't feeling well, but welcome
back!
No, you're getting it just fine. For your item 1 below,
the
default
workspace does just what you want. You never even need
to
know its
there.
Recall the default workspace has a revision selection
rule
containing
checkedout and latest.
For item 2, the model currently allows access through a
specific
revision
name which temporarily overrides the workspace, so this
can
be done
too.
If this was all you wanted, then probably workspaces
for
level 1 would
be
overkill. But, lets look at some other simple scenarios
and
see what
would
happen.
Say a development organization finishes work on a
milestone
and wants
some
way to refer to the proper revisions. When work
continues,
these
revisions
won't necessarily be the latest revision because the
resources may
have
changed in some appropriate way. Configurations solve
this
in level 2,
but
a common scenario for level 1 might be to come up with
a
label for the
release and use this label on every revision that
participates.
So now every time you want to get the R1 revision for
any of
these
resources, you have to remember the revision name and
provide it on
each
access. That's not so bad though, and is the same thing
as
remembering
a
workspace that has checkedout, R1, and latest in its
revision
selection
rule. So far this is a wash.
Now say there's an R2 of the project as a whole. Some of
the
resources
changed and some of them didn't. You could label all
the
participant
revisions with R2 and that would work. But, after a
while
specific
revisions might have a lot of labels on them making the
revision
history of
many resource hard to manage. In addition users have to
remember
something
new, use label R2 instead of R1. An alternative is to
just
label the
ones
that changed with R2 and put checkedout, R2, R1, and
latest
in the
revision
selection rule. Then you'll get the right versions
without
remembering
R1,
R2, ..., you only have to remember the same workspace
you
were using
before
the revisions changed. All users get updated just by
updating their
workspace. The default workspace revision selection rule
can
be
changed
to
so that clients that can't or don't specify a revision
will
get the
right
revisions too. You could do this with default labels,
but it
would
take
a
lot more work to update a property on every resource
resetting its
default
when you can just add a single entry to a revision
selection
rule.
Workspaces just provide flexibility and ease of use for
level 1, not
any
new functionality. I think they make the clients simpler
and
simplify
the
user's interaction with the server. So they are useful
for
level 1
even
though there aren't any activities or configurations.
"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on
02/17/99
03:10:40 PM
To: ckaler@microsoft.com, Jim Amsden/Raleigh/IBM
cc: ietf-dav-versioning@w3.org
Subject: RE: Version issues
It isn't that workspaces provide unneeded functionality
for
Level 1.
It's just an abstraction that a) isn't in simple
versioning
models
now,
so would require learning and understanding, and b)
isn't
necessary.
The way I envision it for a Level 1 implementation is
this:
1. If I request a resource and specify nothing other
than
"get me this
resource" the default is to give me the latest.
Without
branching and
other Level 2 features, this is trivial. With Level 2
implementations,
this is interpreted as the latest on the main line.
2. If I want something other than the latest, I include
a
Revision Id
or a Label. This works fine for both levels, without
any
complexity
whatsoever.
Am I just not getting it?
>>> <jamsden@us.ibm.com> 02/17/99 11:20AM >>>
Comments below in <jra> tags.
Chris Kaler <ckaler@microsoft.com> on 02/17/99 12:13:42
PM
To: Jim Amsden/Raleigh/IBM
cc:
Subject: RE: Version issues
I don't think level 1 servers want to deal with
revision
selection
rules.
I
suspect they could be complicated. As well, we need to
understand the
semantics of parallel checkouts in the "default
workspace".
The
current
definition of a workspaces prohibits this and I think it
is
an
important
requirement for level 1.
<jra>
Level 1 revision selection rules don't need to be
complicated at all.
There
are no activities or configurations, so the revision
selection rule
has
checkedout and 0 or more labels. When a resource is
accessed
with a
simple
URL, this means, get the checked out revision if any,
otherwise look
for a
revision that has a matchin label. It's hard to imagine
anything
simpler.
</jra>
Geoff and I started talking about the Revision-Id
header
yesterday. I
think
it is reasonable for a client to request version X of
/foo/bar.htm.
It
seems a cumbersome requirement to have to set the
revision
of
/foo/bar.htm
in the default workspace to be X and get /foo/bar.htm.
As
well, this
won't
scale at all. Imagine one person trying to get version
X
and one
trying to
get version Y. We clearly need more discussion on this,
but
I don't
yet
see
how we can eliminate a header that specifies a revision.
I
do believe
that
we could condense several headers into one...
<jra>
I also belive that users want to access specific
revisions
given the
label.
If they can assign a label, they should be able to
access
the resource
that
they assigned the label to. Recall that this capability
is
in the
model. In
the new version I moved the method to
Repository.getResource(url :
String,
label : String = null) : Resource. There's also
Repository.getResource(url
: String, context Workspace) : Resource to access a
resource
in the
context
of a workspace. One reason you would want to do this is
if
you want to
look
at an old version, or compare two revisions, and don't
want
to change
your
workspace.
My issue isn't that I didn't want access by labels,
only
that access
when
labels aren't specified should use Workspaces to resolve
the
URL.
</jra>
I, personally, think that RSR are interesting but
probably
too
complicated
for level 1 servers. We could say that the SETDEFAULT
method is a
"utility"
method that modifies the workspace to use the specified
revision of
the
specified resource. This allows us to still describe
level
1
functionality
in the context of level 2 workspaces. And for level 2,
it
provides a
handy
service for augmenting an RSR without having to pull
it,
modify it,
and
put
it.
<jra>
Again, I don't think revision selection rules are
complicate
at all,
especially for level 1 which doesn't have activities,
merging, or
configurations. The complexity results from introducing
multiple
revisions.
Leaving workspaces out of level 1 will just move the
complexity to the
client or user who have to remember lots of labels on a
resource by
resource basis. This makes the server simpler, but not
WebDAV.
I stress again, what would anyone want to do with
versioning
level 1
that
workspaces wouldn't support? What would workspaces
include
that would
be
considered too much for level 1? We need specific
scenarios
that
address
these issues. As you know, I am also keen to keep
things
simple. Its
just I
want the simplicity for the users and clients, not
necessarily just
for
the
server.
</jra>
Thoughts?
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Tuesday, February 16, 1999 12:56 PM
To: Chris Kaler
Subject: RE: Version issues
But if we keep the Revision-Id header and a SETDEFAULT
method, this
will
conflict with level using a default workspace. I suggest
we
effectively
use
default workspaces for level 1. This doesn't mean
servers
have to
implement
them, only do something that makes them look like they
work.
Clients
should
be able to use level 1 services without being aware of
workspaces. If
activities and configurations are not in level 1, then
the
workspace
only
has to consider revision selection rules that include
checkedout,
latest,
and revision labels. This should be pretty simple.
Chris Kaler <ckaler@microsoft.com> on 02/16/99 03:21:30
PM
To: Jim Amsden/Raleigh/IBM, ietf-dav-versioning@w3.org
cc:
Subject: RE: Version issues
[CK] Comments below...
A few issues came up at our last versioning working
group
meeting:
1. DAV versioning level 1 will still need to be a way
of
resolving
access
to versioned resources given just a URL (and not a
label).
If
workspaces
aren't supported, level 1 servers will have to provide
some
other way
to
resolve URLs to specific revisions, perhaps a default
revision for
each
versioned resource. For level 2 servers that do support
workspaces,
this
would result in two, potentially conflicting ways of
performing URL
mapping. This is a strong argument for including
workspaces
in level
1.
What would anyone want to do with versioning level 1
that
workspaces
wouldn't support? What would workspaces include that
would
be
considered
too much for level 1? If there are no compelling answers
to
these
questions, we should include workspaces in level 1,
including the
default
workspace.
[CK] I suggest we keep the Revision-Id header and the
SETDEFAULT
method.
2. Deleting a resource must explicitly state that the
resource is
removed
from its parent collection; that is, the collection
with
which the
resource
is an internal member. Versioning complicates delete
semantics. There
are
three things we might want to delete: an unversioned or
working
resource, a
revision (and all its descendents?) of a versioned
resource,
a
versioned
resource and all its revision history. This must be done
in
the
context
of
versioned and unversioned collections that contain the
resource, or
versioned resource as an internal member. The preferred
way
to do this
would be to have add and remove methods on collections
to
create and
delete
resources as its the collection that controls the
namespace.
Unfortunately,
DAV doesn't have those semantics, so we will have to
find a
work-around
for
versioning.
[CK] I expect deleting a working resource to be the same
as
UNCHECKOUT.
[CK] Deleting a versioned resource is up to the store.
Some
stores
might
[CK] just delete it. Some might create an "delete"
version.
I don't
think
[CK] we want to push a specific model on people.
Especially
since the
[CK] DELETE method is about a resource and in no way
describes the
[CK] underlying repository actions.
Actually, the current WebDAV spec is a little confusing
about
collections
and their members. The current spec indicates
collections
contain
URLs,
not
resources. But, there is the notion of internal members
and
referential
members, and deleting a collection deletes all its
internal
members.
So
the
collection behaves like it contains resources, not
URLs.
This issue
will
likely get more confusing when we add versioned
resources,
versioned
collections, and multiple revisions.
[CK]Your right -- some clarification here would be
could.
3. It is not possible to automatically create workspaces
or
activities
for
either non-versioning clients, or versioning clients
that
don't
specify
them. Default workspaces and/or activities must be
used.
Creating a
new
workspace or activity on each request could cause
resources
that were
manipulated in the previous request to disappear.
[CK] If we say this is what "logically" happens on a
Level 1
server
then
[CK] OK. But if the server must in fact do this, then
I
think the
cost
[CK] is too high since Level 1 clients don't care about
this
information.