[
Lists Home |
Date Index |
Thread Index
]
- To: Paul Prescod <paul@prescod.net>,xml-dev@lists.xml.org
- Subject: Re: [xml-dev] REST as RPC done right
- From: Alaric Snell <alaric@alaric-snell.com>
- Date: Fri, 1 Mar 2002 11:49:57 +0000
- In-reply-to: <3C7EA003.B12560E3@prescod.net>
- References: <4F4182C71C1FDD4BA0937A7EB7B8B4C1045A1776@red-msg-08.redmond.corp.microsoft.com> <3C7EA003.B12560E3@prescod.net>
On Thursday 28 February 2002 21:24, Paul Prescod wrote:
> I don't understand what middleware has to do with it. I'll ask the
> question again: do you know of a protocol that bills itself as RPC where
> the core method names are predefined in advance by the protocol? Is FTP
> an RPC protocol? If not, why not?
> 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).
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 think RPC on top of HTTP is bad, purely because HTTP is an application. RPC
goes beneath it. This is how things should be.
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
