Next message: jamsden@us.ibm.com: "Re: WebDAV Versioning Scenarios"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568B3.000ED5BD.00@d54mta03.raleigh.ibm.com>
Date: Thu, 30 Mar 2000 21:41:59 -0500
Subject: RE: Questions on activities
<jimW>
there doesn't appear to be any constraint that the revisions need to be
on the same branch.
</jimW>
<jra>
There is a statement that all revisions have to be long to the same line of
descent. See the definition for Activity.
</jra>
<jimW>
OK, if the client chooses the name, this could lead to namespace
collisions.
How can a client be guaranteed of selecting a unique name without having to
retrieve a listing of all the names of all the activities? Especially if
the activities are kept as a flat list in a single collection, this listing
could have hundreds or thousands of entries.
</jimW>
<jra>
That's why I don't think the server should specify that all activities have
to be in the /repository/activities collection. We wouldn't want to design
a server that had to put all html files in the /html collection (although
many servers do start that way - as if the site was really just one
application).
As far as namespace collisions are concerned, this isn't a new problem. A
client should just get the members of a collection they are thinking about
adding a member to, and see what names aren't used.
I really believe servers should not be assigning names to client created
resources.
</jra>
<jimW>
For example, the tendency is for this activity
to grow without bounds, since over time every new change will be dependent
on a large number of other changes. There needs to be some way to take a
snapshot and say that, as of this snapshot, all dependencies have been
accounted for. After the snapshot, the dependency tree can start being
built
again. Without this occasional clearing away of the prior dependencies, it
seems to me the revision selection rules would grow larger and larger, and
servers would be less efficient at evaluating the continually growing
revision selection rules.
</jimW>
<jra>
This is exactly what a configuration is for.
</jra>