HTTP-NG has just been OSId by XML-RPC IMHO. Sometime last week. There
are XML-RPC bindings for Perl, Python, Userland Frontier, and Java, and
a significant application (the Sports Illustrated Goodwill Games web
site) has already been deployed built on XML-RPC, something like four
months ago.
Implementing XML-RPC is approximately as difficult as implementing
HTTP/0.9.
> The IETF has traditionally developed application protocols directly on
> top of a raw TCP stream. However, there is a growing set of problems which
> many application protocols have to solve regardless of what the
> protocols do. This WG will identify these problems,
Here they are:
- event notification: sometimes events happen to things. Agents want
to know when particular kinds of events happen to particular things.
Application protocols need to be able to notify agents when this
happens, and provide full information about the event.
- doing stuff: sometimes agents do stuff to things. Sometimes doing
stuff causes events to happen to the thing you're doing stuff to.
Sometimes it causes the thing's state to change. Application protocols
need to provide methods for agents to do stuff to things.
- thing state: sometimes agents want to find out about the state of
some things. Sometimes thing state changes; when thing state changes,
an event happens to that thing. Application protocols need to provide
methods for agents to find out about the state of things.
- agents: agents are things too sometimes.
Some (obviously incomplete) examples:
Events Stuff Things State Agents Applic
-------------------------------------------------------------------------------
none GET,POST "resources" contents, metadata HTTP clients WWW
/msg,/join /msg,/join users,channels who's on, /mode lusers IRC
new article read,post articles, ngs contents, articles users Netnews
new mail send mail recipients mailbox contents senders email
subscribe subscribe mailing lists who's on the list subscribers majordomo
Is it useful to describe all of these as part of a single framework in
order to build diverse applications on top of that framework? I think
so. In particular, I think that each of these applications listed
above has done a poor job in certain areas, things it would get for
free if it were built on top of a higher-level substrate than TCP:
HTTP: fault-tolerance, bandwidth usage, response time, security, remote access,
economic equity (due to bandwidth usage patterns)
IRC: fault-tolerance, security
Netnews: disk usage, bandwidth usage (per server), security
email: remote access
majordomo: uniformity, security
I think these applications would benefit greatly from being rebuilt on
top of a higher-level protocol substrate, in that they would be greatly
improved in the areas mentioned, and they would be much simpler to
implement.
This is what I meant when I said "The age of the *TP is OVER." a couple
of days ago.
I haven't included remote login (telnet, rlogin) because I don't know
if the higher-level framework would benefit it, and I suspect that
interactive response would suffer. Raw TCP is ideally suited to remote
login.
So: am I a raving lunatic or what, FoRKers? ?
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> Computers are the tools of the devil. It is as simple as that. There is no monotheism strong enough that it cannot be shaken by Unix or any Microsoft product. The devil is real. He lives inside C programs. -- philg@mit.edu