--basedir, --config, --verbose, --safe may now come before or after
subcommands and should still be evaluated.
For the server commands (legacy, "server" and "daemon"), the same
should now hold true for the related parameters --host, --port, --debug,
--logging, --iknowwhatimdoing and also --pid (for daemon command).
While having the parameters belong to the individual commands and only
there (which is click's basic approach) is way more cleaner, too many people
were running into issues with that strict approach after all.
I just hope the somewhat hackish approach with context injection needed to
get the less strict version to work won't backfire badly in the long run.
See also #1633 and #1657
--version is a flag, not an actual parameter (wouldn't really make sense
too). I'm not sure why that isn't the default behaviour of the built-in
version_option decorator tbh.
See #1647
Two problems solved:
* Make sure to only process temperature data once we
have printer profile information on hand to evaluate
the heater data. If we don't have that yet, create a client
side backlog and process that once we have the necessary
data on hand.
* Do not use uninitialized history cutoff values - if our cutoff
value hasn't yet synced (no settings response arrived yet),
just don't perform the cutoff.
That api endpoint really is a tough nut. ETag calculation now also
takes full settings dump from settings plugins into account, because
those might be providing custom keys through custom on_settings_load
implementations, for which we will not notice any changes if we are
only looking at the effective config.
Of course, the more we put into that ETag calculation, the slower it will
be and the less sense it will make. Somewhat annoying :/
Not testing if oldRoot was actually set and contained the
key in question could cause issues if a completely new data
structure was sent to the backend that was not mirrored by
the default settings. Things like e.g. complex configuration
items in a by default empty object.
sarge's "wait_events" is unreliable. If an asynchronous
job is started but stops immediately and raises a sarge
Exception (inside the async thread), the associated
command's event will never be set event though the
process finished. So we'd wait indefinitely here.
We circumvent this by first waiting until the commands
are parsed and processed (p.commands contains
elements), then until said commands are started and then
making sure the command's process is actually set. Only
then do we actually have a background process running
that we'll be able to monitor further down, otherwise
the command immediately failed.
Removed a potential deadlock, added logging for all
raised exceptions, made _to_error more solid and
removed another potential encoding issue when
creating diffs
">=4.0.2,<4.1" will pull in 4.1b and we don't want that due to issue with
that and websocket communication due to permessage-deflate.
While we desperately need to migrate to a newer tornado, due to some
voodoo needed to get large streamed uploads and downloads to work
that is probably not completely straightforward and therefore
something for post-1.3.0-stable release.
