Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 57A28B44 for ; Mon, 13 Mar 2017 18:11:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F86519B for ; Mon, 13 Mar 2017 18:11:10 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id v186so46922500wmd.0 for ; Mon, 13 Mar 2017 11:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0P7pjizw6/Md77UvrR6IgDQKyj5a67zqvH/YH9YAAeE=; b=cn8WP1jkRLgHdcpQg9Tf3yyAMjPV5MpP7qJB44IbKmsay1a7kHwfDXJiEVJG/Xv16o S+D0mHw4ATCx5EFME/9TS8PwEdeak1xve6mXOHrIe75MD2qDdEP/2AeljmnywukRFuPT tRPnTHohZRwkXxXVTrbQV69xTthbmINslxfW0jgX0vdzfHK26EEOwcsWZNCMl8aVLKeD kbyFlDSJbWPqXRsoLmrdl8ol5jewvqlW4RGjoJ1Qbsix17WiYQBDCqPhouFml47hZ6wa FJnEJZUzErPyty4tsFBNI3KcyIq5cZjgBEjMnM9BGsiCqreYaQTMUGHUqwXtmHSSM8WM O5OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0P7pjizw6/Md77UvrR6IgDQKyj5a67zqvH/YH9YAAeE=; b=h7yXoREiuIZPrYg4d424z/GefpHEzZkUNNJ9P4IEJSUr34hHJEOW72/h02YfF3m/xu 8SvYzGGQsTvH228BspNSGx3dnozSx8ZLVXTwws3OAHJpU8gnm5r88TFBPxqplqn+RZif Cl7KaPH8EVLQziJFSA6QnvZPEDdksKuHfmLgFvIf2zX1cgWYEdzy27gC09dkUGKfrIeL +n+leR2ei1+PUukbA1vZSZGVRttzEpHNfk42ddsXQv3t13Luvd3e0HCpHYNzgzCl63WV OfSHOZnulKT1UThsWmJd82x7A3xmiC7RkFCuCh0LT7ku90NcNUtPlLNQyk2vvl4ZdmNi OM0w== X-Gm-Message-State: AFeK/H2+EFWaVl7wZPGzrQuoKIp0ANA+ze1MWowdM4K24yzgul833vh/THTd2XQAeGORe0FeMyXebWoPREmMHQ== X-Received: by 10.28.137.211 with SMTP id l202mr11015172wmd.118.1489428668886; Mon, 13 Mar 2017 11:11:08 -0700 (PDT) MIME-Version: 1.0 References: <201703040827.33798.luke@dashjr.org> In-Reply-To: From: Andrew LeCody Date: Mon, 13 Mar 2017 18:10:57 +0000 Message-ID: To: Marcel Jamin , Bitcoin Protocol Discussion , Luke Dashjr Content-Type: multipart/alternative; boundary=001a11444496ba3715054aa0a2db X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 13 Mar 2017 18:13:47 +0000 Subject: Re: [bitcoin-dev] Currency/exchange rate information API X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:11:11 -0000 --001a11444496ba3715054aa0a2db Content-Type: text/plain; charset=UTF-8 This formatting of JSON isn't unheard of though, it's typically called JSON Streaming[1]. As long as exchanges implementing the API actually follow the BIP and keep one JSON object per line, it shouldn't be a problem to decode. 1. https://en.wikipedia.org/wiki/JSON_Streaming On Tue, Mar 7, 2017 at 8:07 AM Marcel Jamin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Why are multiple results separated by a line-feed rather than using a > JSON Array? > > * Clients ought to cache historical data, and using a line-feed format > allows them to simply append to a cache file. > > * Parsing JSON typically requires the entire data parsed together as a > single memory object. Using simple lines to separate results, however, > allows parsing a single result at a time. > > What if long descriptions require line and paragraph breaks? > > * Clients should word-wrap long lines, and JSON escapes newlines as "\n" > which can be used doubly ("\n\n") for paragraph breaks. > > I'd file this under premature optimization at the cost of > interoperability. If you use JSON, then please use it properly. > > I'd also say it's the job of the parser to offer a way of doing that, > e.g. in .NET you can easily achieve that with Newtonsoft's JSON > parser: > http://stackoverflow.com/questions/20374083/deserialize-json-array-stream-one-item-at-a-time > . > > On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev > wrote: > > > > Investigating what it would take to add fiat currency information to > Bitcoin > > Knots, I noticed Electrum currently has many implementations, one for > each > > exchange rate provider, due to lack of a common format for such data. > > > > Therefore, I put together an initial draft of a BIP that could > standardise > > this so wallets (or other software) and exchange rate providers can > simply > > interoperate without a lot of overhead reimplementing the same thing many > > ways. > > > > One thing I am unsure about, is that currently this draft requires using > XBT > > (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis, but > those > > don't really have a pseudo-ISO currency code to fit in nicely... > > > > Current draft here: > > > https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.mediawiki > > > > Thoughts? Anything critical missing? Ways to make the interface better? > > > > Luke > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11444496ba3715054aa0a2db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This formatting of JSON isn't unheard of though, it= 9;s typically called JSON Streaming[1]. As long as exchanges implementing t= he API actually follow the BIP and keep one JSON object per line, it should= n't be a problem to decode.


O= n Tue, Mar 7, 2017 at 8:07 AM Marcel Jamin via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.org> wrote:
> Why are= multiple results separated by a line-feed rather than using a JSON Array?<= br class=3D"gmail_msg"> > * Clients ought to cache historical data, and using a line-feed format= allows them to simply append to a cache file.
> * Parsing JSON typically requires the entire data parsed together as a= single memory object. Using simple lines to separate results, however, all= ows parsing a single result at a time.
> What if long descriptions require line and paragraph breaks?
> * Clients should word-wrap long lines, and JSON escapes newlines as &q= uot;\n" which can be used doubly ("\n\n") for paragraph brea= ks.

I'd file this under premature optimization at the cost of
interoperability. If you use JSON, then please use it properly.

I'd also say it's the job of the parser to offer a way of doing tha= t,
e.g. in .NET you can easily achieve that with Newtonsoft's JSON
parser: http://stackoverflow.com/questions/20374083/deserialize= -json-array-stream-one-item-at-a-time.

On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote= :
>
> Investigating what it would take to add fiat currency information to B= itcoin
> Knots, I noticed Electrum currently has many implementations, one for = each
> exchange rate provider, due to lack of a common format for such data.<= br class=3D"gmail_msg"> >
> Therefore, I put together an initial draft of a BIP that could standar= dise
> this so wallets (or other software) and exchange rate providers can si= mply
> interoperate without a lot of overhead reimplementing the same thing m= any
> ways.
>
> One thing I am unsure about, is that currently this draft requires usi= ng XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis, but= those
> don't really have a pseudo-ISO currency code to fit in nicely... >
> Current draft here:
>=C2=A0 =C2=A0 =C2=A0https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgr= ate.mediawiki
>
> Thoughts? Anything critical missing? Ways to make the interface better= ?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists= .linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--001a11444496ba3715054aa0a2db--