Message-ID: <4F52204D.1040504@justmoon.de>
Date: Sat, 03 Mar 2012 14:44:45 +0100
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com>
In-Reply-To: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Content-Type: multipart/alternative;
	boundary="------------070900020800010201070002"
Subject: Re: [Bitcoin-development] JSON-RPC is BIP territory or not?
Precedence: list

This is a multi-part message in MIME format.
--------------070900020800010201070002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Since several independent clients (I know at least libcoin 
<https://github.com/ceptacle/libcoin/blob/master/src/coinHTTP/RequestHandler.cpp> 
and BitcoinJS 
<https://github.com/bitcoinjs/bitcoinjs-server/tree/master/lib/rpc>) aim 
to implement JSON-RPC APIs which are either a superset of the original 
client's or have at least some compatible functions, I think you can 
make a case for including JSON-RPC API calls within the domain of BIPs.

In this instance the BIP aims to create a common protocol between 
different clients, miners, mining proxies and pools. That's a lot of 
software, so standardization definitely seems like a good idea and I 
can't think of a reason not to use the BIP process.

I have some comments on the content of the BIP, but since this thread is 
more of a meta-discussion I'll wait until the BIP is officially proposed.


On 3/2/2012 7:51 PM, Amir Taaki wrote:
> Hi,
>
> I got sent this BIP:
>
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool
>
> What is your opinion on this? Is it BIP related?
>
> It is a implementation-specific non-bitcoin-protocol proposal. My 
> understanding of BIPs is that
> they apply across bitcoin implementations and largely focus on the 
> most generic use-cases
> (like the URIs) and the protocol. Things which affect all clients, and 
> allow the system to function
> as a united whole.
>
> That BIPs especially focus on the protocol, and that something like 
> this is outside the mandate
> of the BIP process.
>
> For instance, we could imagine a future scenario. Bitcoin-Qt is 
> currently based off bitcoind's
> codebase. However wumpus built the client in mind with an abstraction 
> layer to enable multiple
> backends (a good design). In our hypothetical situation, there are 3 
> different backend codebases
> using Bitcoin-Qt. I do not think a proposal to mandate a changing to 
> Bitcoin-Qt's abstraction
> layer or a change in the UI placement would be appropriate BIP material.
>
> OTOH, many clients do need to make use of URIs and the BIP process is 
> totally correct, as it
> standardises a behaviour which is needed for interoperability of the 
> network and community.
>
> Thoughts?
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--------------070900020800010201070002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Since several independent clients (I know at least <a
href="https://github.com/ceptacle/libcoin/blob/master/src/coinHTTP/RequestHandler.cpp">libcoin</a>
    and <a
      href="https://github.com/bitcoinjs/bitcoinjs-server/tree/master/lib/rpc">BitcoinJS</a>)
    aim to implement JSON-RPC APIs which are either a superset of the
    original client's or have at least some compatible functions, I
    think you can make a case for including JSON-RPC API calls within
    the domain of BIPs.<br>
    <br>
    In this instance the BIP aims to create a common protocol between
    different clients, miners, mining proxies and pools. That's a lot of
    software, so standardization definitely seems like a good idea and I
    can't think of a reason not to use the BIP process.<br>
    <br>
    I have some comments on the content of the BIP, but since this
    thread is more of a meta-discussion I'll wait until the BIP is
    officially proposed.<br>
    <br>
    <br>
    On 3/2/2012 7:51 PM, Amir Taaki wrote:
    <blockquote
      cite="mid:1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff; font-family:times
        new roman, new york, times, serif;font-size:12pt">
        <div>Hi,</div>
        <div><br>
        </div>
        <div>I got sent this BIP:</div>
        <div><br>
        </div>
        <div><a moz-do-not-send="true"
href="https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool">https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool</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 generic use-cases</div>
        <div>(like the URIs) and the protocol. Things which affect all
          clients, and allow the system to function</div>
        <div>as a united whole.</div>
        <div><br>
        </div>
        <div>That BIPs especially focus on the protocol, and 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="font-size: 12pt; ">Bitcoin-Qt. I do not
            think a proposal to mandate a changing to Bitcoin-Qt's
            abstraction</span></div>
        <div>layer or a change in the 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 totally correct, as it</div>
        <div>standardises a behaviour which is needed for
          interoperability of the network and community.</div>
        <div><br>
        </div>
        <div>Thoughts?</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
Virtualization &amp; Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
<a class="moz-txt-link-freetext" href="http://www.accelacomm.com/jaw/sfnl/114/51521223/">http://www.accelacomm.com/jaw/sfnl/114/51521223/</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070900020800010201070002--