Well that is a "simple" hashing procedure, no current mining software works that way. Part of the blockheader include the timestamp. The timestamp doesn't need to be exact so there is no reason to not run the entire nonce range and return any found shares.
With X-Roll-NTime the local miner software can increment the timestamp for a period of time further reducing the number of getworks needed. In theory if X-Roll-NTime was set to say 300 sec, the local miner could continually update the block header until it gets a longpoll (notification of change in blockheader -usually because new block is found). IIRC most pools use a more conservative n-time-rolling value of say 10-30 sec.
Ok so what he's talking only applies to pool mining then.
No what he is talking about applies to nothing. It is a "simple" mining algorithm. No mining software uses. Production mining software use optimizations like being loose with timestamp, using ntime rolling, checking for more than one share per nonce, nonce-range splitting (to improve response time - GPU are non-responsive while hashing a nonce range), etc. All of these are used regardless of if you are solomining or pool mining.
Real code is far more complex. What as presented was just a simplified version. It would work but it isn't optimal.
You seem to think solo-mining is different than pool mining. They really aren't. In solo-mining you are communicating directly to your bitcoind but you still request work and return found blocks. In pool mining you are making the same communications but with a pool server and you also return "shares" (low difficulty hashes) which acts as proof of work in addition to any found blocks.