[
Lists Home |
Date Index |
Thread Index
]
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
|
