RE: Yaron.Redirect.ClientUpdate

Geoff, I hope you aren't seriously expecting me to engage in a debate with
you whose foundation is the need to preserve pretty method names. It really
doesn't matter if the name is SUBSCRIBE or S#*&!@. Other than the later will
probably cause more typo-s.

If using multiple names will help interoperability and my experience leads
me to believe that this is so, then we should use multiple names. To hell
with conserving pretty names.

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@Rational.Com]
> Sent: Thu, February 24, 2000 8:32 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Yaron.Redirect.ClientUpdate
> 
> 
> 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. 
> 
> Cheers,
> Geoff
> 
> > -----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 Friday, 25 February 2000 01:56:48 UTC