Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfYvY-00034R-Iy for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 15:59:12 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.47 as permitted sender) client-ip=209.85.210.47; envelope-from=laanwj@gmail.com; helo=mail-pz0-f47.google.com; Received: from mail-pz0-f47.google.com ([209.85.210.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1SfYvU-0004pT-RN for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 15:59:12 +0000 Received: by dalh21 with SMTP id h21so4173966dal.34 for ; Fri, 15 Jun 2012 08:59:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.240.99 with SMTP id vz3mr21870301pbc.60.1339775942919; Fri, 15 Jun 2012 08:59:02 -0700 (PDT) Received: by 10.143.44.2 with HTTP; Fri, 15 Jun 2012 08:59:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 17:59:02 +0200 Message-ID: From: Wladimir To: Peter Vessenes Content-Type: multipart/alternative; boundary=047d7b3396ad28061d04c284e578 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (laanwj[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SfYvU-0004pT-RN Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Suggestion for Simplifying development work 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: Fri, 15 Jun 2012 15:59:12 -0000 --047d7b3396ad28061d04c284e578 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 15, 2012 at 4:59 PM, Peter Vessenes wrote: > Hi all, > > I've been wondering about whether it would be possible to wipe out the GUI > completely from the satoshi client, and reimplement any necessary data > requests as RPC calls, allowing us to fork -QT and other GUIs over and > (hopefully) dramatically simplifying the codebase that you all have to work > on. > Splitting the UI into a seperate *process* is a long-term goal. The UI code is structured so that all communication with the core happens through a "bottleneck" (consisting of the model classes), so preparation has been under way. However, the current RPC calls don't suffice to implement a full-featured, responsive UI. I'm not even sure JSON-RPC is a good fit for a UI<->core protocol, as it doesn't support bidirectional communication (at least without pretty ugly hacks). But what exactly is the problem with having a GUI as part of the main client project? I don't see how it would "speed up development" to split the project. By far most of the users use the program through the UI so it is one of the drivers for requirements on the core, and I'd think it is pretty important to keep it a first-class citizen. Wladimir --047d7b3396ad28061d04c284e578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15, 2012 at 4:59 PM, Peter Vesse= nes <peter@coinlab.com> wrote:
Hi all,

I've been wondering about whether it would b= e possible to wipe out the GUI completely from the satoshi client, and reim= plement any necessary data requests as RPC calls, allowing us to fork -QT a= nd other GUIs over and (hopefully) dramatically simplifying the codebase th= at you all have to work on.

Splitting the UI into a seperate *pro= cess* is a long-term goal.=C2=A0The UI code is structured so that all commu= nication with the core happens through a "bottleneck" (consisting= of the model classes), so preparation has been under way.

However, the current RPC calls don't suffice to imp= lement a full-featured, responsive UI. I'm not even sure JSON-RPC is a = good fit for a UI<->core protocol, as it doesn't support bidirect= ional communication (at least without pretty ugly hacks).=C2=A0

But what exactly is the problem with having a GUI= as part of the main client project? I don't see how it would "spe= ed up development" to split the project. By far most of the users use = the program through the UI so it is one of the drivers for requirements on = the core, and I'd think it is pretty important to keep it a first-class= citizen.

Wladimir

--047d7b3396ad28061d04c284e578--