The callback architecture could be such that other code would never need to enter into the wallet-handling process/memory space. For instance, client applications could subscribe a particular URL to get sent an HTTP POST.
For the apps I've been working on, there really isn't any need to access the wallet space. I was talking more about events like "A new transaction was just seen" or "A new block was just seen", like what libcoin seems to support (sorry, Michael, I haven't really had a chance to look at it in depth but I will). Then there are other types of events for other bitcoin messages could also be useful: new addr, new node connected, node disconnected, bitcoin alert, etc... Then there are events for dealing with potential attacks: DoS attempt, double-spend attempts (two transactions seen with valid signatures claiming the same output), node sending malformed messages, etc... And then there are alerts pertaining to the status of the bitcoind process itself: bitcoind started, bitcoind ready to accept connections, bitcoind stopping, etc... None of these events require the callback subscriber to have any access to the bitcoind process/memory space and all the I/O could be done via IPC or over network sockets. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
