Web Things, Mark Baker points to some original work on XML-RPC from 1998. This reminded me of some earlier work on XML over HTTP that was published on the W3C site. Here's an interesting quote from that paper:
Predicating the system on HTTP, URIs, and XML tightly constrains the solution set thereby increasing interoperability.
Another great quote:
One of the principles of this design is that if a client needs asynchronous notification then this should be accomplished via the HTTP protocol. This implies an HTTP daemon on the client. By unifying the Web client browser with a small (code of less than 2K in size has been realized) HTTP daemon, notification can be realized without undesirable timed polling, a bandwidth wasting technique which is beginning to appear more often.
Ah, those were the good old days... but the irony doesn't end. The current WHAT-WG is actively defining a new protocol for network connections within a browser, in order to provide a stateful asynchronous protocol for bidirectional realtime communication capabilities. I just say, put an HTTP listener inside the browser instead - httpd on the client.
4 comments:
So how do we solve the problem of IPv4 address shortage if every damn client PC needs its own address?
Besides problem of IPv4 address space, there is also the problem of users behind a NAT.
In each case, the solution calls for browsers to have an callable end-point in the cloud. This has been done before, in the case of ICQ, where some clients become servers.
Unfortunately, ICQ's file-sending capabilities never seem to work when I need them.
In any case, the main reason (IMO) for NAT *is* IPv4 address shortage.
The web-browser (client) does not need an addressable end-point (an IP address) if it does not receive 'unsolicited requests'.
If the client initiates the connection and further messages use that connection, no unique IP address for the user-agent is actually required.
Using HTTP to initiate a connection allows the client to contact an intermediary (gateway) which receives messages and then forwards them on to the client on the already established connection - just one extra network hop.
Post a Comment