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; 
MIME-Version: 1.0
In-Reply-To: <CAMGNxUuPyS+NCfHaoBuc-dvm+m7wyqj2sUReyZiP3hbEQnNeRg@mail.gmail.com>
References: <CAMGNxUuPyS+NCfHaoBuc-dvm+m7wyqj2sUReyZiP3hbEQnNeRg@mail.gmail.com>
Date: Fri, 15 Jun 2012 17:59:02 +0200
Message-ID: <CA+s+GJBrXL0QVPraM6mR1_ZpRtVri_kN6iy5Q8C0_EegrL+_6w@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: multipart/alternative; boundary=047d7b3396ad28061d04c284e578
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Suggestion for Simplifying development
	work
Precedence: list

--047d7b3396ad28061d04c284e578
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 15, 2012 at 4:59 PM, Peter Vessenes <peter@coinlab.com> 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

<br><div class=3D"gmail_quote">On Fri, Jun 15, 2012 at 4:59 PM, Peter Vesse=
nes <span dir=3D"ltr">&lt;<a href=3D"mailto:peter@coinlab.com" target=3D"_b=
lank">peter@coinlab.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
Hi all,<div><br></div><div>I&#39;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.</div>
</blockquote><div><br></div><div><div>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 &quot;bottleneck&quot; (consisting=
 of the model classes), so preparation has been under way.</div>
<div><br></div><div>However, the current RPC calls don&#39;t suffice to imp=
lement a full-featured, responsive UI. I&#39;m not even sure JSON-RPC is a =
good fit for a UI&lt;-&gt;core protocol, as it doesn&#39;t support bidirect=
ional communication (at least without pretty ugly hacks).=C2=A0</div>
</div><div><br></div><div>But what exactly is the problem with having a GUI=
 as part of the main client project? I don&#39;t see how it would &quot;spe=
ed up development&quot; 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&#39;d think it is pretty important to keep it a first-class=
 citizen.</div>
<div><br></div><div>Wladimir</div><div><br></div></div>

--047d7b3396ad28061d04c284e578--