This now just sets a kill reply instead of committing directly.
First, this seems like the more sane thing to do.
Second, we have an iffy race condition where we call Reply.commit()
before the addonmanager finishes its invocation, the proxy thread then progresses
and sets a new flow.reply attribute, and the addonmanager then gets confused
when finishing. This commit doesn't fix that, but mitigates it for Flow.kill
which is now committed by the addonmanager.
The type system was scattered over a number of places, making it hard to
follow. This collects all command types in types.py, and completion, validation
and parsing for each type is centralised. We should use the same mechanism for
options.
The types name is valuable, and we have a better use for it in collecting and
exposing types for options and commands.
The coretypes module should probably be split up anyway - it contains a
threading base class, a few container objects, and the defintion of our
serialization protocol. I was tempted to rename it to "uncagegorized" for the
sake of honesty.
The JS test assets depend in a brittle way on the details of the tflow()
utility functions. We shouldn't have to fix JS tests when adjusting these.
Options:
- Manually generate the test assets in a script.
- Define the JS assets without using tflow, so they don't unexpextedly
vary.
- Remove shortcuts for request, response, etc. - we don't need them if we have completion
- Restrict cuts specification to a set of prefixes
- Extend cuts to add a few more items
This represents a command passed as an argument. Also split arguments from
command values themselves, making the command help for meta-commands much
clearer.
This resolves as a string during MyPy checks, but at runtime has an additional
attribute that is a command that returns valid options.
This is very ugly and clumsy, basically because MyPy is super restrictive about
what it accepts as a type. Almost any attempt to construct these types in a
more sophisticated way fails in one way or another. I'm open to suggestions.