[bisq-network/bisq] API CLI output formatting that is unix-idiomatic and machine-friendly (#4348)
dmos62
notifications at github.com
Wed Jul 1 14:30:32 UTC 2020
The new gRPC API CLI client will be outputting various types of data and we want the output format, just like the rest of the CLI client, to be unix-idiomatic. By unix-idomatic, I mean following the unix philosophy, which, most notably, includes interoperating well with other unix standard tools. The idea is for the output logic to be simple and to be able to achieve complex use cases by piping to other simple and standard tools.
## Table format
Currently, the output of `getoffers` call looks more or less like this (below output is a bit dated; some things like the datetime format has changed, but currently I don't have access to my dev workspace, so using this):
```
Buy/Sell Price in USD for 1 BTC BTC(min - max) USD(min - max) Payment Method Creation Date ID
BUY 9,485.9500 0.03250000 - 0.06250000 308 - 593 Cash Deposit Jun 21, 2020 10:49:46 PM nywdxnx-e77596af-c7e9-4df0-b2cd-86a83eb717d1-135
BUY 9,675.6690 0.07860000 761 Zelle Jun 22, 2020 10:27:40 AM CCQZCI-fa41db95-f002-4ebe-83b0-c2be2d5573a6-134
```
Above output is not easy to destructure automatically. For example, using spaces to distinguish columns is not possible:
```
#!/bin/bash
function drop_header {
tail -n +2
}
function squeeze_spaces {
tr -s " "
}
function space_delimited_table {
column -t -s " "
}
cat current-getoffers-output.txt \
| drop_header \
| squeeze_spaces \
| space_delimited_table
```
Outputs a garbled table:
```
BUY 9,485.9500 0.03250000 - 0.06250000 308 - 593 Cash Deposit Jun 21, 2020 10:49:46 PM nywdxnx-e77596af-c7e9-4df0-b2cd-86a83eb717d1-135
BUY 9,675.6690 0.07860000 761 Zelle Jun 22, 2020 10:27:40 AM CCQZCI-fa41db95-f002-4ebe-83b0-c2be2d5573a6-134
```
The motivation behind current formatting is human friendliness, but, after giving it more thought, true developer friendliness requires easy programmatic output interpretation.
We can use a simpler columnar format with explicit delimiters (only whitespace between columns has been changed):
```
Buy/Sell|Price in USD for 1 BTC|BTC(min - max)|USD(min - max)|Payment Method|Creation Date|ID
BUY|9,485.9500|0.03250000 - 0.06250000|308 - 593|Cash Deposit|Jun 21, 2020 10:49:46 PM|nywdxnx-e77596af-c7e9-4df0-b2cd-86a83eb717d1-135
BUY|9,675.6690|0.07860000|761|Zelle|Jun 22, 2020 10:27:40 AM|CCQZCI-fa41db95-f002-4ebe-83b0-c2be2d5573a6-134
```
To format into a human friendly table:
```
#!/bin/bash
function custom_delimiter_table {
column -t -s "|"
}
cat proposed-getoffers-output.txt \
| custom_delimiter_table
```
Output:
```
Buy/Sell Price in USD for 1 BTC BTC(min - max) USD(min - max) Payment Method Creation Date ID
BUY 9,485.9500 0.03250000 - 0.06250000 308 - 593 Cash Deposit Jun 21, 2020 10:49:46 PM nywdxnx-e77596af-c7e9-4df0-b2cd-86a83eb717d1-135
BUY 9,675.6690 0.07860000 761 Zelle Jun 22, 2020 10:27:40 AM CCQZCI-fa41db95-f002-4ebe-83b0-c2be2d5573a6-134
```
This requires the data to not include the delimiter, which might seem fiddly, but can be solved by allowing the user to specify a custom delimiter (e.g. `|||||`). Unless data in question might contain malicious input, sanitization shouldn't be necessary.
## Column complexity
Another concern is that some columns are difficult to machine parse, because they're optimized for space efficiency and general human readability.
For example, the column titled `BTC(min - max)` can either contain the offer quantity or the offer quantity range, which means it can contain two different types of data: a hyphen-deliminated tuple of floats (`0.03250000 - 0.06250000`) or a single float (`0.03250000`).
The column `BTC(min - max)` can be unpacked into two columns `minimum BTC quantity` and `maximum BTC quantity`. That way we have the same information, but the complexity is reduced (both columns are just floats). When the quantity is a range, the new columns will have different values; otherwise, they will be the same. Same goes for `UTC(min -max)`.
## More data in rows
There's some information, like the offer pair (e.g. BTC and USD), that's embedded in the header, but not in the data rows. That makes it impossible to mix multiple currency pairs in the same table. If pair information was in the rows, you could query `getoffers` for multiple pairs at once, or greatly simplify subscribing to push updates (one subscription for any number of pairs); in short, a table that stores all information in the rows is easier to work with.
Instead of `Price in USD for 1 BTC|BTC(min - max)|USD(min - max)`, we could have:
```Price|Base currency|Base currency quantity(min - max)|Quote currency|Quote currency quantity(min - max)```
or with the above proposed change
```Price|Base currency|Minimum base currency quantity|Maximum base currency quantity|Quote currency|Minimum quote currency quantity|Maximum quote currency quantity```
Some notes:
- some abbreviations might be useful;
- also, notice that `Price in USD for 1 BTC` implies it is the value of base currency being quoted against the quote currency, so I shortened it to `Price`;
- see this article for definitions of currency pairs, base currency and quote currency: https://www.investopedia.com/terms/c/currencypair.asp ;
- notice that the last example is considerably more verbose than the current table format, but it is much easier to machine parse (all cells are simple types with simple semantics); ease and simplicity of setting up machine parsing is the priority.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/4348
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200701/14d246f7/attachment.html>
More information about the bisq-github
mailing list