- From: Keith Moore <moore@cs.utk.edu>
- Date: Fri, 14 Dec 2001 20:56:53 -0500
- To: Mark Baker <distobj@acm.org>
- cc: brian@hursley.ibm.com (Brian E Carpenter), moore@cs.utk.edu (Keith Moore), janssen@parc.xerox.com, discuss@apps.ietf.org
> > I can't see any basic reason why a thermostat should be accessed as if > > it was a hypertext document. > > I would do it for the same reason that anything ends up on the Web; > > - I can manipulate it from the same app I use to manipulate so much of > my life already; the browser > - it can leverage existing and yet-to-be-developed extensions such as > WebDAV so that access to it can be locked, versioned, etc.. > - if I forget its URL, Google can find it for me > - if my house network is unreliable, an existing cache on the network > can let me know what the last cached state of my thermostat is, and > when that state snapshot was taken > - authentication for free > - content negotiation permits my french-speaking serviceman to > also manipulate and debug it remotely through the same URL > > etc.. though you might like them for your thermostat, you're making a false assumption that such things are desirable for thermostats, or any other application, in general . > If that isn't reason enough for you, then do it just to prevent the > APPS area from needing 10 area directors by the end of the decade. 8-) given the complexity and weaknesses of HTTP and the wide variety of behavior in the deployed HTTP infrastructure, it's often more work to figure out and specify how to use HTTP to do something, than it is to design your own protocol. HTTP often works okay on a small scale. But I have yet to see someone suggest using HTTP for a widely-used protocol who truly understood the implications of that design choice. Keith
Received on Friday, 14 December 2001 21:10:10 UTC