Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=elombrozo@gmail.com;
	helo=mail-ob0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <201203221000.41636.luke@dashjr.org>
References: <CABr1YTc0TOvfyFNY4CTaOiTa3WWb-5JHjQOTarB=8zZ+DqiUFg@mail.gmail.com>
	<201203221000.41636.luke@dashjr.org>
Date: Thu, 22 Mar 2012 08:23:17 -0700
Message-ID: <CABr1YTd4+KES75cHqKSa0Gwz62nJnMVsTANVh_qzuSXqoYZAew@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] Adding callback hooks to the satoshi
	client
Precedence: list

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.