Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QhHwe-00080R-6w for bitcoin-development@lists.sourceforge.net; Thu, 14 Jul 2011 09:10:56 +0000 X-ACL-Warn: Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] helo=cavuit01.kulnet.kuleuven.be) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QhHwa-0002sG-91 for bitcoin-development@lists.sourceforge.net; Thu, 14 Jul 2011 09:10:56 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: EB2881380B7.A75CD X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id EB2881380B7; Thu, 14 Jul 2011 11:10:42 +0200 (CEST) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id B8F6B31E702; Thu, 14 Jul 2011 11:10:42 +0200 (CEST) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id BAB6610067; Thu, 14 Jul 2011 11:12:19 +0200 (CEST) Received: by wop.ulyssis.org (Postfix, from userid 615) id BA98D87C1B0; Thu, 14 Jul 2011 11:10:42 +0200 (CEST) Date: Thu, 14 Jul 2011 11:10:42 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: John Smith Message-ID: <20110714091041.GA3814@ulyssis.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QhHwa-0002sG-91 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Notifications from client/wallet X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:10:56 -0000 On Thu, Jul 14, 2011 at 05:19:11AM +0000, John Smith wrote: > Hello all, > > I'd like to add notifications to the client and wallet, to decouple UI and > core communication, and especially so that UIs no longer have to poll for > changes. > > I propose to use the boost::signal mechanism for that. It is basically a > glorified callback system, but allows decoupled delivery of 'signals' from > an object. Multiple other objects can listen in on an event without the > emitting object having to care. I like this idea. Matt and I were considering a similar system for the internal communication between net/wallet/blockdb/mempool, but weren't really aware of boost::signal. I looked at it, and really seems to provide everything necessary. > Specific notifications that would be useful: > > Wallet: > > - balanceChanged(int64): spendable balance changed Maybe even per-account? > - transactionAdded(int256): new transaction added to wallet > - transactionUpdated(int256): transaction info changed Does that include more confirmations? I think we'd first need to define what exactly is relevant information for transactions. It could be defined in terms of a/some high-level information request functions for transactions, so GUI/RPC don't inspect the wallet datastructures themselves anymore: * GetTransactionState(): return state (immature, generated, unconfirmed, rejected, confirmed), and number of confirmations. (possibly using the negative number of confirmations semantics as described here: http://forum.bitcoin.org/index.php?topic=5920.msg328468#msg328468. * GetBroadcasts(): return either -1 (unknown) or some integer denoting how often this tx was broadcast. The "0/offline" state is equal to unconfirmed + 0 broadcasts * GetInputs(): return a list of pairs (uint256 txId, int nOffset, int64 nAmount) * GetOutputsToMe(): return a list of pairs (address addr, string label, fBool isChange, int64 nAmount, bool fGenerated, bool fAvailable) describing all To-Me outputs * GetOutputsToOthers(): return a list of pairs (address addr, string label, int64 nAmount) * GetFee(): get the fee paid The only things that can change while the transaction is already in the wallet seems to be GetTransactionState() and GetBroadcasts(), so those would cause a transactionUpdated event? Adding/removing private keys from the wallet may change the other outputs, so i suppose those are also candidates for causing this event. - transactionRemoved(int256): transaction removed from wallet (can this > happen? for completeness) for now, that can't happen, but if something like unspending/rejecting/detection of conflicting transactions is added, it may. > - addressAdded(int160): address was added to address book > - addressUpdated(int160): address label/other metadata was modified > - addressRemoved(int160): address was removed from address book > - notification(std::string message, int severity): warning/error occured > in wallet processing, notify user Ok. > - int askFee(std::string message, ...): ask user for fee You simply mean the "Transaction requires fee of ..., agree?" message? Regarding wallet encryption, we could use a - string askPassphrase() maybe? > Network client: > > - numConnectionsChanged(int): new connections / connections broken > - numBlocksChanged(int): new blocks came in or other changes to block > chain > - notification(std::string message, int severity): warning/error occured > in network processing, notify user Ok; those would need to be implemented as globals until a more modular structure is implemented. -- Pieter