Current issues are now documented.

To "solve" them, can probably "just give up and use requests", and offload any network issues as "Not My Department".

Need answers:

• Is having a dependency acceptable? (Yes. Otherwise, endless loop of NIH.)
  • So far, krakenex has had no dependencies other than the "standard library". requests is ubiquitous, though, and many distributions provide it as a system-level package, which handles dependencies of requests (urllib3 and chardet on my Arch system, with optional pysocks).
  • Building documentation requires sphinx, which has requests as a dependency.
• Should a "unified" query() be introduced? (No. That can be done independently.)
  • How should it know if an API method is public or private? (See issue Python methods for corresponding Kraken API methods #40.)
    • May maintain a list for one of the two, and default to the other one if not in list; or maintain two lists, and refuse to query if in neither list.
    • Currently, the difference is that private methods need to set API-{Key,Sign} headers, and include a nonce in request data.
    • It seems that having a nonce is not enforced by Kraken for public queries.
  • What should its return format be? (JSON, as now.)
    • Whatever requests returns?
    • JSON, as currently output by query_{private,public}()?
• Should the return format of query_{private,public}() remain the same? (Yes - for now, to remain backwards-compatible. Trivial - return request's .json() where appropriate.)
  • Maybe yes, if query() is not introduced, or to remain backwards-compatible.
  • Maybe no, if to be obsoleted or made private; then query() returns JSON, and these two a requests object, verbatim.
• Should manual connection handling remain possible, or become hidden? (Yes. That's the whole point - give users a non-NIH way of customising the connection.)
  • requests handles Keep-Alive.
  • Allowing to set timeout (in Connection.__init__()) may become unnecessary.

Answers may depend on current/planned use cases.