RE: Comments on current version of the WEBDAV spec

1. A resource is created with a PUT. The author has decided that they
would like the resource to be available under a different URI. How would
you suggest they go about establishing this? What happens if the URI
maps to a server other than the one they are working from? Why do you
feel that this scenario is so compelling for Distributed Authoring and
Versioning?

2. How would you change the HTTP 1.1 spec so as to deal with workspaces?

3. I believe I will address these issues in the post I will be releasing
sometime this weekend (o.k. so Friday slipped =) when I talk about
versioning of structured resources. However, this is somewhat irrelevant
as I do not believe that it is feasible for us to propose any sort of
URL name scheme. For example, a user wants to get version 5 of foo so he
types up http://foo#5 because we have defined that as the format for
referring to version 5 of a document. The server happily returns a
response. Has the user actually gotten version 5 of the document? If the
server doesn't comply w/our URL mangling scheme it could be returning
anything. It is this inability to be certain that kills most mangling
schemes. Of course we can take the "Roy Compromise" which is to get
permission from the server before mangling but this has the problem that
eventually mangling schemes collide with each other and now we need a
scheme to negotiate between the schemes. Of course schemes also change
over time, so now we also need a mechanism to extend and version the
scheme. Before we are done, we have created an entire command system. I
would rather use the command system we already have, HTTP.
BTW what is a project? How does it behave?

4. I'm sorry but I don't see a proposal that I can respond to. Could you
please be more specific?

		Yaron

> -----Original Message-----
> From:	Andre van der Hoek [SMTP:andre@bigtime.cs.colorado.edu]
> Sent:	Friday, March 14, 1997 3:04 PM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Comments on current version of the WEBDAV spec 
> 
> 
> On the risk of this becoming a flame-war which I want like to avoid,
> let me 
> answer here again.  But also, let me ask the rest of the group who is
> reading 
> and paying attention to this e-mail list to also participate.  This is
> 
> absolutely not ment to be a mailing list with few participants (such
> as until 
> now just Yaron and me for this thread), but includes everybody else.
> Yaron is 
> correct in saying the process is about a concensus.
> 
> Now for the answers:
> 
> > I should also clarify that the current spec has absolutely no
> special
> > status. Any spec submitted to the group will be given equal weight.
> The
> > only power the current spec has is that it has proven useful in
> > clarifying issues and helping the group to build consensus.
> 
> I do not understand.  I thought the process was not to have every
> member of 
> the group submit a spec, but to jointly work towards a consensus as
> you said.  
> Part of that is discussing the existing spec, which I am trying to do.
> I do 
> absolutely not have any intent to write a rival spec.  There are many
> things 
> good about the existing spec, it does not make sense to propose a new
> one.  
> Rather, I would like to improve on the existing one, which is all that
> I am 
> trying to do.  Am I misunderstanding the process now?
> 
> > 1. It is generally not a good idea to instruct people as to what
> they
> > should do, I would recommend leaving comments like "Think about it
> > again." out of your responses. Either way, if it so happens that two
> > different URLs point to the same resource then some magic is being
> used
> > on the server side and I don't think DAV wants to get mired in how
> that
> > magic would work. However I would encourage you to look at the
> > AddResource and RemoveResource commands in the current spec.
> 
> First of all: apologies for the "Think about it again".  What I ment
> to say 
> was the following: there are issues that are no covered, and I would
> like to 
> challenge you to address and consider these issues.  For example, I do
> not 
> believe that saying "there is some magic that is being used" is the
> correct 
> way to go for our spec, because it leaves issues open.  I did read the
> spec, 
> and did look at the AddResource and RemoveResource commands, and
> again, do not 
> agree with the "magically showing up in a name space" sentence.  What
> does 
> this mean?  What does membership imply?  How do I magically appear in
> multiple 
> name spaces, under different names, but being in reality the same
> resource?  
> Rather than saying "Think about it again", I encourage you to work out
> this 
> scenario with the current spec, and see whether it can be covered or
> not.  I 
> do not believe so, since I can not see a way for this to magically
> work.  
> Thus, I would like to see the spec address this issue in greater
> detail.
> 
> > 2.The HTTP cache has been designed toward a very specific end, what
> you
> > propose doing would radically alter that design. Furthermore,
> > implementers such as myself would not use the extensions as we will
> not
> > have a wire protocol dictating how we will implement our internal
> > functionality. It is completely appropriate for HTTP to specify how
> > public and multi-user caches operate. However once the bits are off
> the
> > wire, HTTP's purview ends.
> 
> But not necessairly WebDAV's view; that was the whole point of my
> argument.  I 
> do not advocate using the cache, I just see it as an intriguing
> opporunity.  
> Rolling out our own cache/workspace is fine with me too, but I believe
> WebDAV 
> should pay attention to it (and you seem to agree as you are talking
> about 
> synch operations, which implicitly say things about a workspace), and 
> consequently the spec should be addressing aspects of the workspace.
> 
> > 3. I do not see how your solution is any more interoperable than
> using
> > versioning links and history resources. I do however see how your
> > proposal violates the concept of URLs as opaque tokens and robs
> servers
> > of the ability to implement and maintain their namespaces as they
> see
> > fit. As such I do not feel that a standardized URL scheme for naming
> > versions is appropriate.
> 
> My proposal indeed violates the concept of opaque URL tokens; and
> indeed robs 
> server of the ability to implement their namespaces.  However, on
> purpose.  
> Let me try and ask the following question: how does the current WebDAV
> spec 
> address the following functionality: I have project X in 4 versions,
> with a 
> subproject Y with 6 versions, and a member of that subproject, called
> Z in 7 
> versions.  Now I would like to retrieve of version 3 of project X,
> version 5 
> of project Y, menber version 6: i.e.: X -> 3, Y -> 5, Z -> 6.  How do
> I 
> address this particular entity with the current spec, i.e., with the 
> versioning links and history resources? Can I address this entity with
> the 
> current spec? What is its name? Can you show me how I carry out this
> naming? 
> If not: it certainly seems to be an important capability to have. I
> believe it 
> is currently not possible, but so important and desirable, that I am
> willing 
> to violate the design principal. If I don't, any server can implement
> its own 
> naming scheme, and I lose interoperability, because I can not built a
> client 
> that knows about every possible naming scheme. Conclusion: I would
> like to 
> standardize on the name space.
> 
> > 4. For what it is worth, my goal for DAV is not to be the ultimate
> > generic versioning system. We went down that route and found out we
> had
> > an incredibly complex specification that was totally
> non-interoperable
> > due to the amount of negotiation involved.
> 
> I believe that is due to the road taken in this approach.  Larry
> pointed this 
> out in an earlier message: the road taken was one where everything is 
> discoverable and everything is interoperable, that is an undauntly
> difficult 
> task. The alternative taken now is to limit the spec to a small number
> of 
> policies, which I believe is a mistake and underestimate of the
> difficulties 
> that arise. In my earlier message I pointed out a situation that for
> example 
> needs to be addressed (non-locking + locking policy interoperating). I
> think 
> that the same problems as before will show up, slightly smaller scale,
> but 
> certainly as hairy. Therefore I am advocating the different approach,
> also 
> laid out by Larry: provide a generic infrastructure to build policies
> on top 
> of. The current spec is actually pretty close to providing such an 
> infrastructure, and I believe that eventually in the end this will be
> the road 
> that will be taken and the road that will be more succesfull. Summary:
> I 
> believe that by scaling down the number of policies the spec does not
> become 
> significantly easier, the same old hairy discovery and
> interoperability issues 
> remain.
> 
> 
> Do others have any opinions about all of the above?
> 
> Regards,
> 
> === Andre ===

Received on Friday, 14 March 1997 20:34:09 UTC