1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
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 <laanwj@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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"><<a href=3D"mailto:peter@coinlab.com" target=3D"_b=
lank">peter@coinlab.com</a>></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'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 "bottleneck" (consisting=
of the model classes), so preparation has been under way.</div>
<div><br></div><div>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</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'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.</div>
<div><br></div><div>Wladimir</div><div><br></div></div>
--047d7b3396ad28061d04c284e578--
|
