Is there agreement that ideally a bitcoin daemon handing the public block chain and a bitcoin GUI should have a complete and well defined interface between them that could work over a network and allow different daemon and client implementations to work together?
Is it worthwhile to separate the daemon and GUI part of bitcoin-qt so the daemon operates in one process and the GUI in another and communicate over a well defined interface? In this case the daemon would not handle private keys in any way, but the GUI would use the interface to observer transactions for specific public keys.
I am especially interested in this because I have recently implemented accepting bitcoins on my website and found the current JSON-RPC interface lacking. Notably I do not want to store private keys on my web server yet I saw no way to use bitcoind to observe the relevant transactions when they came in short of implementing the bitcoin protocol. I think a good solution to this problem would be a library with bindings for many languages that connects to bitcoind providing an interface where I can supply a public key and chain code for HD wallets and it will provide new keys in the chain and notification when transactions show up matching these keys. This library/interface could provide all functionality needed by a bitcoin GUI. This should significantly reduce the programming effort to implement new software using bitcoin which I think is essential for wide spread adoption for ecommerce in a decentralized way.
I realize BitPay and other services make this process easier which is great but we have an opportunity to make handling bitcoins much easier without relying on a central service.
While I realize this is a significant undertaking I would consider this an important feature. Is anyone else working on this? Is there a better approach or a reason this is a bad idea? Are there other clearly more important features?
I noticed an email on the bitcoin mailing list on 5/16 titled "Modularizing Bitcoin" that seems to suggest something along this lines.