* Base the following on common EDMCCAPIReturn: EDMCFailedrequest,
EDMCCAPIRequest, EDMCCAPIResponse. This saves repeating a bunch of
variable types and comments.
* Use the above throughout the 'Update' button flow.
* Still need to address 'Save Raw Data', i.e. AppWindow.save_raw().
* Still need to change stats.py to use a cached copy of CAPI data,
rather than it querying that itself. That means actually storing that
cached copy whilst in the capi worker.
* Defined inner functions in the worker function to handle the actual
queries. This allows for *them* to simply return data or raise
exceptions to be caught by the main worker function. *IT* then
handles returning any error appropriately via the queue to AppWindow.
* Due to the coupling between AppWindow and these queries there are
several extra parameters passed into the queue worker and then back
out. This is largely due to having to split AppWindow.getandsend()
into two functions: capi_request_data() and capi_handle_response().
This might get changed to use a class to encapsulate those values,
rather than the bare tuple currently being used.
* No full flake8 & mypy pass done yet.
* Some companion.py globals renamed so their use is more obvious.
1. Sending back a spurious CredentialsError() to check it's now handled,
but other issues blocking the code from getting there currently.
2. Move the "Update suit data from CAPI" call into the AppWindow
handler.
3. Move some more of the old query() exception handling into the worker.
4. session.query() no longer returns anything, and neither should
anything that calls it (like session.station()). This is going to
take quite some unwinding and code moving.
Due to main app being Tk we can't just use Python async functionality.
So instead we have a class to hold a message and optional exception.
And instance of that goes into a queue.
The reading of that in the main thread is triggered by sending a Tk
event.
Much more to come.
The file has:
1a. class Session - Frontier Auth
1b. class Session - CAPI queries
1c. class Session - Utility functions (to do with CAPI query data, but
not directly about *making* those queries.
2. Some non-class utility functions.
The former will be used by the latter, so this makes more sense when
reading the code.
In general I'm going to ensure there are two sections to this Session
class:
1. Frontier Auth code.
2. CAPI query code.
Yes, ideally I'd split it into two classes. But that kind of
refactoring isn't for *this* branch. I just want things straight in my
head for the "make CAPI queries run in a thread" changes.
Docked at an EDO settlement means CAPI says we are, but we've forgotten
monitor.station because there's not enough Journal information and too
many corner cases to be *sure* of re-using old data.
