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 Thursday, 24 February 2000 23:44:24 UTC