From: Stefan Thomas <moon@justmoon•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] JSON-RPC is BIP territory or not?
Date: Sat, 03 Mar 2012 14:44:45 +0100 [thread overview]
Message-ID: <4F52204D.1040504@justmoon.de> (raw)
In-Reply-To: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4616 bytes --]
next prev parent reply other threads:[~2012-03-03 13:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 18:51 Amir Taaki
2012-03-02 19:14 ` Luke-Jr
2012-03-03 13:44 ` Stefan Thomas [this message]
2012-03-03 13:49 ` Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F52204D.1040504@justmoon.de \
--to=moon@justmoon$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox