From: Dario Teixeira <dario.teixeira@nleyten.com>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] More precise type information in API reference
Date: Tue, 17 Feb 2015 13:00:49 +0000 [thread overview]
Message-ID: <9ec9df3b0ecb854fa19bd9100ed87d85@nleyten.com> (raw)
Dear Bitcoin devs,
I am the author of OCaml-bitcoin [1], a library offering an OCaml
interface
to the official Bitcoin client API. For those who may be unfamiliar
with it,
OCaml is one of those functional programming languages with a very rich
and
expressive type system [2]. Given its emphasis on safety, its
industrial
users are disproportionally found in the aerospace and financial
sectors.
Now, OCaml programmers care a lot about types, because experience has
taught them that deep down most programming errors are just type errors.
From this stems my request: please consider defining more precisely the
type
information associated with each API call in the JSON-RPC reference [3].
To give you a better idea of what I'm talking about, please take a look
at
the API offered by OCaml-bitcoin [4], and the associated type
definitions
[5] (note that these have not been updated for Bitcoin Core 0.10 yet).
I've created the type definitions from information gathered from the
Bitcoin
wiki and from looking at the Bitcoin Core source-code. I wouldn't be
surprised
if it contains errors, because neither the source-code nor the wiki is
very
precise about the actual types being used. As an example, consider type
hexspk_t ("hex representation of script public key"). Is this really
the
same type used in both signrawtransaction and createmultisig?
Improving this situation would pose a minimal burden on bitcoin devs:
all
that would be required is defining the precise set of types used in the
RPC
API, and annotating the RPC calls either in the source-code itself or in
the
API reference documentation. It would make writing bindings such as
mine
far easier and less error prone, and it would have the added advantage
of
better documenting the Bitcoin Core source-code itself.
Also, note that it is not necessary to extend this request to the deep
data structures returned by some API calls. Consider for instance the
gettransaction function of the OCaml-bitcoin API: it returns the raw
JSON
object without any attempt to process it. This is because that's a
fairly
niche facility, and the bindings would balloon in size if I were to
process
every single large return object. Instead, the bindings take the more
pragmatic stance of only processing the parameters and return results
where
a strong type discipline is imperative.
When I raised this issue on IRC a number of questions were posed.
What follows is my attempt to answer them:
Q: What does it matter, if JSON only has a tiny set of types?
A: JSON being the serialisation format is irrelevant. The client
bindings
know that even if a public ECDSA key is serialised as a string, it
does
not stop being a public ECDSA key, and should only be used where a
public
ECDSA key is expected.
Q: What does it matter if the types are not even distinguished in the
C++
source of Bitcoin Core?
A: That is unfortunate, because it opens the door to bugs caused by
type
errors. Moreover, even if the C++ source is "stringly-typed" and
does
not enforce a strong type discipline, that does not mean that the
types
are not there. Even if a public and private key are both
represented
as strings, can you use one where the other is expected? If not,
then
they actually have different types!
Q: Isn't this a maintenance nightmare, given the changes to Bitcoin
core?
A: Actually, the most burdensome part is what motivated this message:
keeping track of the types used. If the Bitcoin API reference were
more precise, keeping the bindings up-to-date would be trivial and
even mechanical, because the API is now fairly stable.
Thank you very much for your attention, and for all the work you guys
put
into Bitcoin development. It is much appreciated and not acknowledged
often enough!
Best regards,
Dario Teixeira
[1] https://github.com/darioteixeira/ocaml-bitcoin
[2] http://ocaml.org/learn/description.html
[3] https://bitcoin.org/en/developer-reference#bitcoin-core-apis
[4] http://ocaml-bitcoin.forge.ocamlcore.org/apidoc/Bitcoin.ENGINE.html
[5] http://ocaml-bitcoin.forge.ocamlcore.org/apidoc/Bitcoin.html
next reply other threads:[~2015-02-17 13:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 13:00 Dario Teixeira [this message]
2015-02-17 13:33 ` [Bitcoin-development] More precise type information in API reference Dario Teixeira
2015-02-17 15:50 ` David A. Harding
2015-02-17 18:46 ` Dario Teixeira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ec9df3b0ecb854fa19bd9100ed87d85@nleyten.com \
--to=dario.teixeira@nleyten.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox