Hi,
I think that writing mastercoind is an excellent idea, and I have an idea for improvement:
I think that the best way to implement this is by making mastercoind use bitcoind as a backend.
Just like HTTP implementations are using Berkeley sockets and not rewriting them.
The benefits we get by choosing this architecture are simplicity and more important security.
We can now assume that bitcoind is a very secured piece of software.
Few days ago I saw a lecture by Gavin Anderssen where he said that the bitcoin-qt had a lot of security holes in it's early days.
We can't afford security holes in mastercoind, it will not be under the radar like bitcoin-qt in it's early days.
Good point, I'm aiming for the level of security to at least match bitcoind. From a remote exploit prevention, mastercoind is written in python using cherrypy. This fact makes certain types of exploits less likely (e.g. buffer overflows, and other things that could plague writers in lower level languages like C/C++ if they aren't careful with their string length checking). Other vulnerabilities, such as SQL injection, are still possible, and from there it's good coding practices, and doing extensive cleanup/sanity checking on user-provided input (the lack of which is always what leads to these kinds of attacks, essentially).
Then you have things like stored data security. For now at least, RPC username and password are stored in a plaintext settings file, similar to bitcoind. We can look at changing this in the future, however. If something very sensitive is required (such as private wallet key for signing requests), then I plan to collect that as part of the request and not store it, if at all possible.