W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: Yaron.Redirect.ClientUpdate

From: Clemm, Geoff <gclemm@Rational.Com>
Date: Thu, 24 Feb 2000 23:32:09 -0500
Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B024@chef.lex.rational.com>
To: w3c-dist-auth@w3.org
I don't think that the "method for each variant of each operation"
scales.  I can think of 4 or 5 groups that would like to pick SUBSCRIBE
to mean something slightly different.  One of the advantages of live
properties is that they have a built-in namespace mechanism.  I agree
that this will mean that servers will need two extra dispatch points
(i.e. in PROPFIND and PROPPATCH), but I believe that is a small price
to pay in order to avoid name collisions as more extensions to WebDAV
are developed.

Note: there currently are few enough WebDAV extensions, that I could get
the names I want for bindings, redirect references, and even versioning,
but I can already the cursing of subsequent protocol developers
as they discover that all the meaningful method names in their domain
have been used by the first wave of protocol developers. 


> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Thursday, February 24, 2000 1:55 AM
> To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yarong@goland.org'
> Subject: RE: Yaron.Redirect.ClientUpdate
> We can either let them use MKREF to update it or we can introduce a
> UPDATEREFTARGET method. Lately I have been leaning to introducing new
> methods in order to simplify the standard text. Re-using 
> existing methods
> for related functionality has proven to make specs harder to read. For
> example, in my GENA spec I specified that SUBSCRIBE can be 
> used with a NT
> header to create a subscription and with a Subscription-ID 
> header but no NT
> header to renew a subscription. The result is that I had to 
> put in some
> fairly confusing language to explain what to do if a request 
> has both a NT
> and a Subscription-ID header. After that experience I just introduce a
> RESUBSCRIBE method to simplify things. Of course, this isn't a perfect
> solution since the more methods you have the more things 
> people have to put
> on their slides when they explain WebDAV. =)
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Mon, February 21, 2000 12:52 PM
> > To: Yaron Goland; w3c-dist-auth@w3.org
> > Subject: RE: Yaron.Redirect.ClientUpdate
> > 
> > 
> > As long as we have the DAV:reftarget property, the obvious 
> > thing to do is
> > allow clients to update its value.  If you want to get rid of 
> > that property,
> > as it seems you do from NoWebDAV#3, then I suppose we would 
> > need something
> > like an UPDATEREFTARGET method.
> >  
> > --Judy
> > 
> > -----Original Message-----
> > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> > Sent: Friday, February 11, 2000 2:57 AM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: Yaron.Redirect.ClientUpdate
> > 
> > 
> > 
> > Maybe I just missed it but there doesn't seem to be any way 
> > to update the
> > target of a redirection resource without deleting it. I move that a
> > mechanism be provided that enables the target of a 
> > redirection resource to
> > be updated without having to delete the resource.
> > 
Received on Thursday, 24 February 2000 23:44:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT