Subject: RE: Yaron.Redirect.ClientUpdate

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 25 Feb 2000 09:16:44 -0500

OK, I'll admit that was weak.  I will defer to your implementation
experience here, and like Eric, I will start
saying "use a METHOD" in a monotone voice until some stronger
argument occurs to me or someone else (:-).

In particular, I will make a pass through the versioning protocol
and see what impact this would have.

Cheers,
Geoff

> -----Original Message-----
> From: Yaron Goland [mailto:[email-masked]]
> Sent: Friday, February 25, 2000 1:35 AM
> To: 'Clemm, Geoff'; [email-masked]
> Subject: 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:[email-masked]]
> > Sent: Thu, February 24, 2000 8:32 PM
> > To: [email-masked]
> > 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:[email-masked]]
> > > Sent: Thursday, February 24, 2000 1:55 AM
> > > To: 'Slein, Judith A'; [email-masked]; [email-masked]'
> > > 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:[email-masked]]
> > > > Sent: Mon, February 21, 2000 12:52 PM
> > > > To: Yaron Goland; [email-masked]
> > > > 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:[email-masked]]
> > > > Sent: Friday, February 11, 2000 2:57 AM
> > > > To: [email-masked]'
> > > > 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.
> > > > 
> > > 
> > 
>