Communication with Qt is done through the RPC server, however (don't quote me on this) I think it is hardcoded to localhost. Assuming you get accross this hurdle (or that I'm wrong), you still need to give Armory the raw block chain files path. Through a network share, I assume.
Close! Armory actually doesn't use the RPC connection, it connects as a regular peer through localhost. Some people have problems with this because they assume it's RPC, and setup their bitcoin.conf to only accept connections from certain IPs, thinking that Armory will sidestep it through RPC.
However, it only uses that connection for
new blocks and transactions. It still relies on the BTC_HOME_DIR/blocks/blk*.dat files to read the past blockchain history. Now that Armory is maintaining its own database, I can transition off of using the blk*.dat files and
only use the peer connection. But there may be some hurdles there:
(1) Bitcoin-Qt/bitcoind cutting me off because I'm demanding too many resources and it blacklists me
(2)
Please dear god do not connect Armory to an untrusted node!. You will die a fiery death. Armory does absolutely no blockchain validation: it is designed to use that connection as its secure gateway.
I want to eventually allow remote connections, but then also make it painfully obvious that there is a serious risk involved. You might even want to use some kind of SSL to make sure you remote connection is not intercepted. None of this matters though when it's forced to use localhost...