A client that connects up, subscribes, and then gets updates as they happen might be an easier start.
Connects via another port?
Or would you teach bitcoin's minimal http implementation to keep the connection open? (and service multiple connections at once)
As discussed on IRC, bitcoin's JSON-RPC httpd should be converted to use select(2) (or poll or epoll) as is done now in ThreadSocketHandler2(), which enables HTTP/1.1 persistent connections.
But let's leave that aside for a second.
However, for monitorblocks and push mining ("pushwork"), I would urge consideration of running a TCP server on a
third port (8331?) with a simple protocol designed for long-running TCP connections, and data broadcasting.
Server (bitcoind) simplified pseudocode for monitorblocks:
processed_new_block_event(block):
for each incoming TCP connection on port 8331:
if (connection mask & BROADCAST_BLOCK)
write(socket fd, block)
Client simplified pseudocode for monitorblocks:
TCP connect to host:8331
send curtime, protocol version, client version string, username, [possibly empty] list of options, sha256(all previous args + password)
wait for server response ("auth ok, here are my capabilities", or "rejected, goodbye")
send "send me new blocks" message
while (true)
select/poll for new input from remote server (bitcoind)
read message from server ("hi, I'm a new block!")
take client-specific action based on message...
In this manner, bitcoind's logic is simple because you don't have to keep track of a list of monitored URLs, nor care about retrying a monitorblocks HTTP POST if server is down, etc.
This same client connection model can be used for "push" mining, where miners are automatically delivered new work if bitcoind receives a new TX or block from the P2P network.
Server (bitcoind) simplified pseudocode for push mining:
processed_new_block_event(block):
for each incoming TCP connection on port 8331:
if (connection mask & BROADCAST_WORK)
work = RPC.getwork()
write(socket fd, work)
And client miners would behave similarly (warning to efficiency nuts: this is a simplified example):
TCP connect to host:8331
send curtime, protocol version, client version string, username, [possibly empty] list of options, sha256(all previous args + password)
wait for server response ("auth ok, here are my capabilities", or "rejected, goodbye")
send "send me new work" message
start proof-of-work GPU/CPU mining threads in background:
while (true)
send "get work" message
read work from server
execute GPU/CPU miner core
if solution found:
send "found solution" message
while (true)
select/poll for new input from remote server (bitcoind)
read message from server ("hi, I'm a new work unit!")
interrupt GPU/CPU miner core, restart with new work
Or something to that effect.
The general idea is simply a binary protocol and connection model that's efficient for data broadcasting tasks such as: monitorblocks, push mining, and a future monitortx feature.