Andrew LeCody [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-13 📝 Original message:This formatting of JSON ...
📅 Original date posted:2017-03-13
📝 Original message: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 at 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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b8f95ee6/attachment.html>;
📝 Original message: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 at 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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b8f95ee6/attachment.html>;