- From: Werner Donné <werner.donne@re.be>
- Date: Fri, 12 Jan 2007 10:34:51 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jay Daley <jay@nominet.org.uk>, w3c-dist-auth@w3.org
Hi, Implementing an efficient client is a challenge if you have to discover the capabilities at run-time. Either you end up with a lot of OPTIONS method calls or a lot of state to avoid them. Another alternative is recovery code for failures all over the place, because you can't just fail without telling the user in a proper way what the problem is, which depends on the scenario he is in. "Not implemented" is not good enough when it is about something deep inside some logic that the user has triggered, because he will not be able to related it to what he did. Why exactly what Apple did was a mistake? Regards, Werner. Julian Reschke wrote: > > Jay Daley schrieb: >> Hi >> >> Can anyone point me to an explanation as to why WebDAV uses http:// >> as the URI scheme instead of something WebDAV specific that would >> signal when a URI is WebDAV compliant? I've had a go at searching the >> lists but can't find not the reasoning behind it. >> >> thanks in advance > > Well, a WebDAV resource *is* an HTTP resource. Why would you create a > new URI scheme? Would you also create new URI schemes for WebDAV ACL, > WebDAV DeltaV and so on...? (*) > > The capabilities of an HTTP resource can be discovered reliably at > runtime, either by just trying (and let the server fail), or by using > the OPTIONS method. > > Best regards, Julian > > (*) Yes, Apple did something similar with iTunes and iCal, but I think > there's wide agreement that was a mistake. > > -- Werner Donné -- Re Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
Received on Friday, 12 January 2007 09:33:47 UTC