Quote from: apetersson on August 25, 2012, 10:46:16 PM

so it is a rpc client? or does it use p2p commands?

It uses the bitcoin p2p protocol: setting up a connection using TCP 8333, sending version/verack messages and getting data using getblocks and so on.
(just like an original Satoshi client)

Quote from: apetersson on August 25, 2012, 10:46:16 PM

if it ONLY stores the unspent ouputs, how does it react to chain reorganisations?

The standard data flow (no chain reorganisation) is as follows:

New blocks are downloaded first (and pre-processed = extracting info from txs) into "Chain___" tables (block and transaction data) and there is an attempt to determine their block height. This is indicated on screen by the "Count: xxx / yyy blocks" which means: received xxx blocks from yyy in total.
Any block more then 10 blocks deep in the chain gets pruned: tx outputs of each transaction (the new unspent outputs) are added to the "TxOutAvailable" table, tx inputs of each transaction cause their corresponding output deleted from the "TxOutAvailable". If that succeeds, the block is deleted from the chain list (the point of no return so to say)
Status is indicated by "Pruned up to block: zzz", which will be always at least 10 less then "xxx"

If a chain reorganisation happens, the received block does not append to the end of the block chain but some blocks (mostly 1 or 2) deeper down the chain.
As BiRD maintains a chain list (and full block data) of the latest 10 blocks as explained above, it can remove the obsolete (orphaned) blocks and accept the new block instead.
Only if a chain reorganisation should occur more then 10 blocks deep, BiRD will not be able to cope that, but then there is probably something bigger going on (as in attack of the block chain).