This really helped me understand it:
A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.
The getwork RPC call was removed from Bitcoin Core. It was deprecated and then superceded by the getblocktemplate RPC call.
It looks like the pool that you are using uses an unspecified protocol. It's just a tcp connection where you are sending JSON formatted strings and receiving JSON formatted strings from the pool server. I figured this out by digging ...
If you run out of work while waiting for longpoll to finish, then what you should do is submit another getwork request.
Note that just because you find a share in a particular piece of work, doesn't mean that you're done with that piece of work. There still might be shares or even a block solution in there somewhere.
The proof of work that miners do is a double sha256 hash on 80 bytes of data.
Where do the 80 bytes come from?
They are build from enough data to describe the current block (and the transactions it contains) and a pointer to the previous block.
4 bytes version number
32 bytes hash of the previous block
32 bytes Merkle root of all the transactions ...
For everyone else, who stumble upon this question :
I've written a Java wrapper around the JSON-RPC provided by bitcoin/litecoin.
It uses Htmlunit & GoogleGson and quite easy to understand and extend.