We suffer from the same problem as commands being suppressed in the
send queue here. If a non-GCODE-command we send to the printer
produces no output, our _monitor loop will wait until the next response
produced by another command. Which we won't send though since
we are stuck waiting in the _monitor loop waiting for a response. Hence
we need to manually trigger further command processing from the
send loop here in order to ensure things keep going.
Also make sure that if we have a pkg_resources version that returns
tuples we not only remove any intermediary version parts if the base
version is requested, but we also append "*final" to the tuple afterwards,
otherwise the compatibility check will fail.
That way people will not see connection failed messages while the server is
still starting up.
Served intermediary page als "pings" an image on the backend to detect if
a) the backend is still responding at all ("intermediary.gif") and b) whether the
server has fully started up ("online.gif").
If the backend stops responding for 5s, a message is output that tells the user
that something went really wrong and to please check the log file.
Once the server becomes online, the intermediary page reloads/switches to the
actual UI.
When autoscroll was disabled, terminal could run on endlessly, eating
memory until the browser crashes. Now a hard upper limit ensures
that not more than 3000 lines are ever stored in the terminal. If autoscroll
is disabled and the limit is reached, no more log lines will be added. That
ensures that the log will not scroll and the current log excerpt will stay put.
UI + assets should actually have ETag and LastModified headers and proper
IfMatch handling on the server side and hence the server should do the
right thing on its own.
That should improve performance tremendously.
Both ETag and LastModified depend on all files the template rendering
depends on. If any of the depended on files changes, both values will
change as well. That allows us to track whether our cached copy is
still current (and force a refresh if not) and also process IfMatch request
headers and reply with a 304 directly so that we do not even have to
transfer the data if nothing changed and the browser still has it.
