Cart
[Home] [By Thread] [By Date] [Recent Entries]
Alaric Snell wrote: > >... > > > No, in general. FTP works fine without being defined on top of an RPC > > protocol and its used for non-hypertext data. DNS works fine without > > being defined on top of an RPC protocol. I don't see how either protocol > > would be more useful if it were defined on top of an RPC protocol. > > I'd say that HTTP and FTP are all using an implicit RPC protocol called 'send > commands and get responses using CR/LF terminators and varying conventions > about how to encode multi-line things (HTTP uses a blank line as a seperator, > FTP uses that stuff with the '-' characters). I agree. HTTP is not an RPC protocol but it could be viewed as being built on an impicit RPC protocol...an application of RPC. > It would be nice if both of them (and POP and IMAP and ACAP and...) happened > to use a common well-defined RPC protocol. Especially since that would allow > them all to be ported to use UDP, IPX, or whatever in one fell swoop in > future. It would ease implementation of them. I agree here also. It would be nice but it is clearly not a killer issue or these specs would be dead! The application semantics are much more important than the RPC syntax. > I think RPC on top of HTTP is bad, purely because HTTP is an application. RPC > goes beneath it. This is how things should be. I agree once again! I would only use the word "application protocol" rather than "application" as a small nit. Paul Prescod
|
