--- Day changed Sun Nov 04 2018 03:41 < dongcarl> stevenroose: Seems like the dependencies are pretty minimal.. Apparently they use Fowler–Noll–Vo for their header map? Glad the `fnv` crate at least has no dependencies 05:18 < dpc[m]> Any opinions on how a `rust-bitcoincore-rpc` crate API should look like? My doubts include: should the API methods be named `get_block_hash` or `getblockhash`? Should API types balances be `f64` like in internal Json, or more sane `u64` (satoshis)? 11:58 < stevenroose> dpc[m]: in rust-bitcoindrpc I named methods exactly like the core commands (i.e. no snake case etc) and added _verbose suffixes if some commands had different methods. 11:59 < stevenroose> You might want to take a look. I actually recently found a way to overcome the silly macro limitation where you have to repeat the command 12:00 < stevenroose> Also it handles optional arguments pretty nicely by filling in default values only when necessary (f.e. when first optional is not given and second is given) 13:19 < andytoshi> rust-secp 0.11.4 https://github.com/rust-bitcoin/rust-secp256k1/pull/77 13:27 < andytoshi> stevenroose: i think `http` is ok, i agree i wish they weren't using some exotic data structure. `fnv` has no unsafe code. for some reason `http` itself does 13:28 < andytoshi> ah, it's mostly to avoid utf8 checking in already-parsed urls 16:44 < dpc[m]> stevenroose (IRC): This sort of a dilemma comes up often when doing eg. FFI crates. Typically it's solved by having `foo-sys` and `foo` crates where `foo` is more Rust-idiomatic, and `foo-sys` are just plain mappings to underlying foreign code. In this case the divergence would be really small, so I'm leaning towards making the API skewed towards the higher-level. My reasoning is: if someone wants to just call raw 16:44 < dpc[m]> methods by names, they can just use `rust-jsonrpc` directly. I've iven proposed adding a conveniance function: https://github.com/apoelstra/rust-jsonrpc/pull/19/commits/484b45e5aaf8ecc53449e9466f81ba3e3cbc4334 . So eg. getting a block is just `jsonrpc_client.do_rpc("getblock", &[block_hash.into(), 1.into()])`. No need for any libraries other than `jsonrcp`. Then `rust-bitcoincore-rpc` would be (already is) two crates: 16:44 < dpc[m]> one containing just raw JsonRpc types (so like a -sys crate), and the main one: which would offer integration with `rust-bitcoin` types, all the niceness and best practices. 19:12 < stevenroose> dpc[m]: not sure what that was a response to. I prefer to almost always have the utility functions. However, in the calls that have a verbose-like response that also contains a "hex" field, I created a getter method to the utility struct that parses the hex field. 19:12 < stevenroose> Because often the verbose responses have metadata that the utility type from rust-bitcoin doesn't show 20:21 < dpc[m]> I was just thinking aloud about API look.