Next message: Geoffrey M. Clemm: "new "Advanced Versioning Semantics" section"
Date: Tue, 25 Apr 2000 23:25:35 -0400 (EDT)
Message-Id: <200004260325.XAA02563@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Questions on activities
From: jamsden@us.ibm.com
If servers have such an implementation, then they are free to put the
resources anywhere they want, provide any keys they want, etc. The user's
URL is simply a binding to the server-managed resource. There may be no
other bindings, and the server may not even support the BIND method. The
user need never know anything about the server's implementation or where
and/or how it physically stores the resource, what keys it uses to access
it, etc. This is true for any resource type, not just activities.
Web servers commonly do not provide a general URL-to-resource mapping
mechanism. They determine what repository is handling that segment of
the URL namespace, and hand the URL over to that repository for handling,
including name to resource mapping.
It is very important the protocol stays implementation neutral to maximize
server implementation flexibility.
Allowing the server to constrain the namespace of where activities can
be created increases server implementation flexibility (that's the whole
point).
So I still don't see why activity names must be managed by the
server. But we continue to have similar discussions. Perhaps I'm
missing something.
I believe what you are missing is that the underlying repository is
responsible for maintaining the URL to resource mapping, while the Web
server only has a high level notion of which portion of the URL space
are being maintained by which server. This means that the web server
will not be able to hide repository defined limitations on the activity
namespace.
Cheers,
Geoff