Date: Wed, 18 Nov 1992 10:04:15 +0000 (GMT) From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk> Subject: Smart server or smart client ? To: www-talk@nxoc01.cern.ch In-Reply-To: Putz.parc@xerox.com's message of Tue, 17 Nov 1992 12:13:13 PST: <92Nov17.121323pst.58401@spoggles.parc.xerox.com> Message-Id: <Ximap.722084834.9952.khoadley@danton> Steve Putz wrote: >I like the idea of your suggested INPUT tag. It seems like a logical >extension of the current protocol, and I can think of many uses for it, >including form-based queries and maybe even a server-based Hypertext editor ============================= >running on a very simple generic client. > >Steve Putz >Xerox PARC > > This raises the question of smart servers vs smart clients. How much does the client need to know about format conversion ? The client knows what formats it understands (maybe extensible through a system like a MIME mailcap), but does it need to know about how to convert between different formats ? Adding format conversion into the clients will make them much more complicated, which is usually not a good thing (witness the success of POP over IMAP in the PC mail market: POP is simple minded, easy to implement and as a result widespread; IMAP is a rather nice protocol, fairly powerful, but more difficult to implement (though not THAT difficult). RESULT: though IMAP is technically far superior to POP, POP is winning the war.) Thus I think it would be a good idea to keep the clients simple, shunt the complexity where possible into the server (it doesnt matter much if ther are only one or two server implementations; it matters a great deal however if the clients are only limited to certain Unix boxes). I think we can learn from the way the DNS works. The are two types of DNS queries: iterative and recursive. With an iterative query, the client (resolver) sends a query to one server. From the result it may be referred to another server, which it then queries and so on until it reaches a conclusion. With a recursive query, the resolver (a stub resolver) sends the initial query (with the RR bit set) to a local server, which then does all the work. The protocol remains the same in both cases, the actual procedure of lookup remains the same, they differ only in whether the local resolver does all the work or simply punts it to a local server. The best way to support small machines such as PCs, Macs, Amigas etc within the WWW would seem to me to support the concept of a stub client that merely throws everything at the server and leaves it to sort out the mess. When the stub client connects to the server it informs the server what formats it understands (lists out its wwwcap ?). Compatibility with existing clients can be maintained in that if a client doesn't inform the server of the formats it knows, we can asssume a minimum (HTML + plain text ?). This can be extended further... consider a site running a firewall, limiting access to the outside to a few selected hosts (poor misguided people !). If I'm sitting on a PC and I'm reading a document with a link to another document outside my site, that link is useless to me because I cant access the outside world. On the other hand a central site server might have external access, thus if I can punt the query to the server and say "you go fetch this for me" everything is hunkydory. The underlying protocol doesn't change, all that happens is that I can ask any server to get me the answer, rather than just the right one. Again look at the DNS. The great advantage of stub resolver is that they lead to a centralised cache at the local server. If we punt www queries to a local server we get the same: the ability to build a cache of the information regularly used by the locals (I'm writing from a research lab with a heavy slant towards high energy physics - thus there is likely to a slant in the documents that users around here want; cacheing this working set would be a big win.) (For this cacheing to work well we'd need to associate a time to live with each document - again like the DNS). It should be possible to cache format conversions as well. Anyway, these are just some ideas, maybe useful maybe not. Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk