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 <melvincarvalho@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; 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: <CA+s+GJDqRBFpGS-8rsjodiCscD_swG9mZ=R0EQO+rVi_ed=Kcw@mail.gmail.com> References: <CA+s+GJA3-qK71TcUCYQ3xOdi+zgE_fB9N6NJkNBUDtWnA-0dcA@mail.gmail.com> <CAKaEYhJfY+zhnzWBa76u+=o1jAsxG-+j5c6RYDS+nhSDi1QDQQ@mail.gmail.com> <CA+s+GJDqRBFpGS-8rsjodiCscD_swG9mZ=R0EQO+rVi_ed=Kcw@mail.gmail.com> Date: Mon, 27 Oct 2014 12:24:13 +0100 Message-ID: <CAKaEYh+suOdfnJ=GN6v_Gp=yNh4n2Bp+juv89BgBwZ_Mo+GfjQ@mail.gmail.com> From: Melvin Carvalho <melvincarvalho@gmail.com> To: Wladimir <laanwj@gmail.com> 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 <bitcoin-development@lists.sourceforge.net> 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: <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: Mon, 27 Oct 2014 11:24:22 -0000 --001a11c341ca3b0031050665c547 Content-Type: text/plain; charset=UTF-8 On 27 October 2014 08:49, Wladimir <laanwj@gmail.com> wrote: > On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho > <melvincarvalho@gmail.com> 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 <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On 27 October 2014 08:49, Wladimir <span dir=3D"ltr"><<a href=3D"mai= lto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>></span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sun, Oct 26, 2014= at 12:44 PM, Melvin Carvalho<br> <<a href=3D"mailto:melvincarvalho@gmail.com">melvincarvalho@gmail.com</a= >> wrote:<br> <br> > Firstly, apologies in coming in late to the conversation.=C2=A0 As I a= m also<br> > working on a REST API for electronic coins.=C2=A0 Some questions:<br> ><br> > 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST o= utput<br> > e.g. the response format and MIME types.=C2=A0 Or just compile from so= urce?<br> <br> </span>See the opening post from @jgarzik, it has some documentation on how= <br> to use the API.<br> <br> It would be nice to have some write-up about the current functionality<br> in the release notes, but there currently is none.<br> <br> It's a RPC-side change, not a P2P-side change so it doesn't require= a BIP.<br></blockquote><div><br></div><div>Thanks.=C2=A0 Yes, I worked thi= s out after looking at the code.<br><br></div><div>I would be happy to help= with documentation.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> <span class=3D""><br> > 2. How set in stone is v1 of the the going forward?=C2=A0 PS I support= @maaku's<br> > comments re: "/api/v1/" -- tho I guess it is too late for th= at now.<br> > 3. Would there be any support to develop this interface into something= that<br> > would be W3C standards compliant, or reviewed by the REST community.= =C2=A0 So for<br> > example a context can be provided to self document the terms (somethin= g I've<br> > almost completed) and would allow standardization of block explorer an= d<br> > bitcoind outputs.=C2=A0 Right now every explorer seems to have a diffe= rent JSON<br> > output.<br> <br> </span>It's not too late, it's not been merged yet.<br> <br> Though a W3C standard takes a long time to pan out, and it may be more<br> useful to have this available rather than wait for the API to be<br> standardized (which means this will need to be postponed at least one<br> version). As you say, a new interface be added later under another<br> URI.<br></blockquote><div><br></div><div>Agree.=C2=A0 I think these changes= are great for 0.10.=C2=A0 <br></div><div>=C2=A0</div><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <br> Note that we're only interested in exposing read-only, public data<br> which is already available in Bitcoin Core's internals.<br> We're not aiming to add a fully-fledged block explorer with (say)<br> address indexes. Although that could be part of the standard if it<br> allows implementations to support just a subset.<br></blockquote><div><br><= /div><div>Got it thanks.<br></div><div>=C2=A0</div><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <br> Anyhow - please coordinate this with Jeff Garzik, it's better to work<b= r> together here.<br></blockquote><div><br></div><div>Will do.=C2=A0 Work in t= his area is ongoing, both in terms of coding/patches/testing and documentat= ion.=C2=A0 <br><br></div><div>Do you think it would a reasonable idea to pu= t down some thoughts and proposals in a BIP?<br></div><div>=C2=A0</div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Wladimir<br> </font></span></blockquote></div><br></div></div> --001a11c341ca3b0031050665c547--