- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 10 Mar 1999 14:45:51 -0800
- To: "'Keith Moore'" <moore@cs.utk.edu>
- Cc: web@apps.ietf.org, discuss@apps.ietf.org
> I do agree with you, however, that HTTP provides most of the features > needed by most client-server applications. If the application only > needs to do RPC like things (even with moderately large payloads), > doesn't need efficiency (most don't), and isn't likely to be heavily > used or used over wireless links, or multicast, then HTTP is probably > fine. However wireless is likely to become a lot more important very > soon and that to me is enough by itself to make HTTP a very dubious > contender as a base for future applications. (similarly for > SMTP and IMAP) My own experience shows that HTTP works like a champ over wireless. Its large granularity commands work extremely well over high latency links. However it may be that the particular usage profiles I'm involved with are biased in a manner which make HTTP function properly. What issues do you have with HTTP over unicast and multicast UDP? > > > P.S. As for HTTP's complexity. HTTP itself is an unbelievably simple > > protocol. The problem is that it has inherited a lot of > cruft over the > > years, 99.99% of which is optional and not widely > supported. I believe that > > what the world really needs is a re-written version of the > HTTP spec. One > > organized into a more rational structure which shows the > true beauty of > > HTTP's layered architecture. I would be willing to bet that > one could write > > a spec providing the absolute bare minimum information > needed to create a > > compliant client/proxy/server in 20 pages. > > That seems like a stretch - in particular the interaction of cacheing > proxies is just too complex. But I'd love to see somebody try. > Caching proxies are simple, **IF** you only do the basic caching that actual works. People run into problems when they try to get fancy and support features no one needs or uses. I would bet you could explain the entire minimally compliant/maximally useful HTTP proxy caching system in two pages. > Keith > Yaron
Received on Wednesday, 10 March 1999 17:47:15 UTC