Message-ID: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Fri, 2 Mar 2012 10:51:41 -0800 (PST)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="285087016-776446052-1330714301=:3840"
Subject: [Bitcoin-development] JSON-RPC is BIP territory or not?
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

--285087016-776446052-1330714301=:3840
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0AI got sent this BIP:=0A=0Ahttps://en.bitcoin.it/wiki/BIP_DRAFT:_ge=
tmemorypool#JSON-RPC_Method:_getmemorypool=0A=0A=0AWhat is your opinion on =
this? Is it BIP related?=0A=0AIt is a implementation-specific non-bitcoin-p=
rotocol proposal. My understanding of BIPs is that=0Athey apply across bitc=
oin implementations and largely focus on the most generic use-cases=0A(like=
 the URIs) and the protocol. Things which affect all clients, and allow the=
 system to function=0Aas a united whole.=0A=0AThat BIPs especially focus on=
 the protocol, and that something like this is outside the mandate=0Aof the=
 BIP process.=0A=0AFor instance, we could imagine a future scenario. Bitcoi=
n-Qt is currently based off bitcoind's=0Acodebase. However wumpus built the=
 client in mind with an abstraction layer to enable multiple=0Abackends (a =
good design). In our hypothetical situation, there are 3 different backend =
codebases=0Ausing=A0Bitcoin-Qt. I do not think a proposal to mandate a chan=
ging to Bitcoin-Qt's abstraction=0Alayer or a change in the UI placement wo=
uld be appropriate BIP material.=0A=0AOTOH, many clients do need to make us=
e of URIs and the BIP process is totally correct, as it=0Astandardises a be=
haviour which is needed for interoperability of the network and community.=
=0A=0AThoughts?
--285087016-776446052-1330714301=:3840
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div><b=
r></div><div>I got sent this BIP:</div><div><br></div><div><a href=3D"https=
://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypo=
ol">https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_ge=
tmemorypool</a><br></div><div><br></div><div>What is your opinion on this? =
Is it BIP related?</div><div><br></div><div>It is a implementation-specific=
 non-bitcoin-protocol proposal. My understanding of BIPs is that</div><div>=
they apply across bitcoin implementations and largely focus on the most gen=
eric use-cases</div><div>(like the URIs) and the protocol. Things which aff=
ect all clients, and allow the system to function</div><div>as a united who=
le.</div><div><br></div><div>That BIPs especially focus on the protocol, an=
d that something like this is outside the mandate</div><div>of the BIP
 process.</div><div><br></div><div>For instance, we could imagine a future =
scenario. Bitcoin-Qt is currently based off bitcoind's</div><div>codebase. =
However wumpus built the client in mind with an abstraction layer to enable=
 multiple</div><div>backends (a good design). In our hypothetical situation=
, there are 3 different backend codebases</div><div>using&nbsp;<span style=
=3D"font-size: 12pt; ">Bitcoin-Qt. I do not think a proposal to mandate a c=
hanging to Bitcoin-Qt's abstraction</span></div><div>layer or a change in t=
he UI placement would be appropriate BIP material.</div><div><br></div><div=
>OTOH, many clients do need to make use of URIs and the BIP process is tota=
lly correct, as it</div><div>standardises a behaviour which is needed for i=
nteroperability of the network and community.</div><div><br></div><div>Thou=
ghts?</div></div></body></html>
--285087016-776446052-1330714301=:3840--