Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XiiPO-00085T-0y for bitcoin-development@lists.sourceforge.net; Mon, 27 Oct 2014 11:24:22 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.179 as permitted sender) client-ip=209.85.217.179; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f179.google.com; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XiiPM-000733-NH for bitcoin-development@lists.sourceforge.net; Mon, 27 Oct 2014 11:24:21 +0000 Received: by mail-lb0-f179.google.com with SMTP id w7so892710lbi.10 for ; Mon, 27 Oct 2014 04:24:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.198.226 with SMTP id jf2mr8900580lbc.84.1414409053992; Mon, 27 Oct 2014 04:24:13 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Mon, 27 Oct 2014 04:24:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Oct 2014 12:24:13 +0100 Message-ID: From: Melvin Carvalho To: Wladimir Content-Type: multipart/alternative; boundary=001a11c341ca3b0031050665c547 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 (melvincarvalho[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: 1XiiPM-000733-NH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:24:22 -0000 --001a11c341ca3b0031050665c547 Content-Type: text/plain; charset=UTF-8 On 27 October 2014 08:49, Wladimir wrote: > On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho > wrote: > > > Firstly, apologies in coming in late to the conversation. As I am also > > working on a REST API for electronic coins. Some questions: > > > > 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST > output > > e.g. the response format and MIME types. Or just compile from source? > > See the opening post from @jgarzik, it has some documentation on how > to use the API. > > It would be nice to have some write-up about the current functionality > in the release notes, but there currently is none. > > It's a RPC-side change, not a P2P-side change so it doesn't require a BIP. > Thanks. Yes, I worked this out after looking at the code. I would be happy to help with documentation. > > > 2. How set in stone is v1 of the the going forward? PS I support > @maaku's > > comments re: "/api/v1/" -- tho I guess it is too late for that now. > > 3. Would there be any support to develop this interface into something > that > > would be W3C standards compliant, or reviewed by the REST community. So > for > > example a context can be provided to self document the terms (something > I've > > almost completed) and would allow standardization of block explorer and > > bitcoind outputs. Right now every explorer seems to have a different > JSON > > output. > > It's not too late, it's not been merged yet. > > Though a W3C standard takes a long time to pan out, and it may be more > useful to have this available rather than wait for the API to be > standardized (which means this will need to be postponed at least one > version). As you say, a new interface be added later under another > URI. > Agree. I think these changes are great for 0.10. > > Note that we're only interested in exposing read-only, public data > which is already available in Bitcoin Core's internals. > We're not aiming to add a fully-fledged block explorer with (say) > address indexes. Although that could be part of the standard if it > allows implementations to support just a subset. > Got it thanks. > > Anyhow - please coordinate this with Jeff Garzik, it's better to work > together here. > Will do. Work in this area is ongoing, both in terms of coding/patches/testing and documentation. Do you think it would a reasonable idea to put down some thoughts and proposals in a BIP? > > Wladimir > --001a11c341ca3b0031050665c547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 October 2014 08:49, Wladimir <laanwj@gmail.com> wro= te:
On Sun, Oct 26, 2014= at 12:44 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:

> Firstly, apologies in coming in late to the conversation.=C2=A0 As I a= m also
> working on a REST API for electronic coins.=C2=A0 Some questions:
>
> 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST o= utput
> e.g. the response format and MIME types.=C2=A0 Or just compile from so= urce?

See the opening post from @jgarzik, it has some documentation on how=
to use the API.

It would be nice to have some write-up about the current functionality
in the release notes, but there currently is none.

It's a RPC-side change, not a P2P-side change so it doesn't require= a BIP.


> 2. How set in stone is v1 of the the going forward?=C2=A0 PS I support= @maaku's
> comments re: "/api/v1/" -- tho I guess it is too late for th= at now.
> 3. Would there be any support to develop this interface into something= that
> would be W3C standards compliant, or reviewed by the REST community.= =C2=A0 So for
> example a context can be provided to self document the terms (somethin= g I've
> almost completed) and would allow standardization of block explorer an= d
> bitcoind outputs.=C2=A0 Right now every explorer seems to have a diffe= rent JSON
> output.

It's not too late, it's not been merged yet.

Though a W3C standard takes a long time to pan out, and it may be more
useful to have this available rather than wait for the API to be
standardized (which means this will need to be postponed at least one
version). As you say, a new interface be added later under another
URI.


Note that we're only interested in exposing read-only, public data
which is already available in Bitcoin Core's internals.
We're not aiming to add a fully-fledged block explorer with (say)
address indexes. Although that could be part of the standard if it
allows implementations to support just a subset.

--001a11c341ca3b0031050665c547--