* Session.profile() was unused (used to be called from stats.py, but
that uses cached data now).
* Session.query() was unused, other than by itself. Normal calls will
currently be via companion.Session.station(). Future CAPI queries
like `/fleetcarrier` might add their own companion.Session function.
* And in doing so get --capi-pretend-down working again.
* Small tweak to EDMarketConnector to not throw extra exception if there
was a CAPI query exception.
NB: We can't use a generator here to make a python object of the data,
to then use json.dumps() on because the raw_data is a *string* (decoded
from what we received from the CAPI service), and thus it will get
encoded as such, i.e.
"raw_data": "{\"id\":322...
when we want:
"raw_data": {"id":322...
We do not want to json.loads() that string only to then json.dumps() it
because the whole point is that this is the **raw** data to help
diagnose any issues with the CAPI service/data. Such a conversion and
back could either throw an exception we don't want here (because we want
the raw data) or possibly distort things from what was actually
received.
* If we don't invalidate then the companion.Auth code will do nothing
due to "already auth'd".
* We need to give the auth flow time to complete, so need to return.
* As that auth flow can take indeterminate time, not setting a timed
retry of the CAPI query here. We should consider setting a flag and
reacting in the Auth code though.
I keep observing it take 3-4s to update the UI after a manual CAPI
request. This showed up as mostly *in*
AppWindow.capi_handle_response(), but the moment I ran it under PyCharm
profile that went down to 400ms.
* The 'EDMC' prefix on all these classes is to make it clear they're for
internal passing around of requests/responses, rather than holding the
literal raw CAPI request and response.
* The request and response queues are now commented, including the
detail that the response queue is created by the caller and then set
'here' by Session.set_capi_response_queue().
This should have been set from the latest Journal file, and the
key/value is in LoadGame in Odyssey. It's only documented as:
"Whether the sending Cmdr has an Odyssey expansion."
in the current EDDN Journal schema. Thus sending this as False if the
Cmdr last logged into Horizons/base game should be OK.
* It's no use `dict(CAPIData)` if that contains other `CAPIData`. So,
rather than write something to do that recursively just implement a
simple JSON Encoder class and specify its use.
EDMC.py will also need to make CAPI queries using the new threaded
method, but it has no tkinter, thus we need to pass in the event name
when we expect one to be generated, and only generate it if this is not
None.
