benjetson / pipanel Goto Github PK

At the present time, it is not possible to identify which request from the server caused an error to occur. Primarily, this is caused by the lack of context at the handler level.

• Incoming request contexts need to be tagged with a request identifier so that they can be mapped back to the request that triggered them in the logs.
• Context needs to be an argument to all request handlers.
• PiPanel needs a custom logger that accepts a context as a parameter, writing the request ID with the log messages.

Use pkg/errors package for wrapping errors to improve traceability; attach a stack trace to all errors.

Server should defer a recovery function that will return control to the server in the event a handler triggers a panic. It may be useful to implement middleware to achieve this effect on all requests.

The current implementation of TTSAlerter causes the request handler to hang while the alert message is read. If the message is long, this significantly delays the time for responding to the request.

Consider handling this asynchronously.

• Font size preference
• Window size preference
• Icon size preference
• Default icon preference
• Default timeout preference
• Min/Max timeout preference
• Enable/disable perpetual alerts

Several tasks in PiPanel are completed asynchronously by request handlers, often without any goroutine monitoring the results. Handling of these errors needs to be improved, at the minimum writing a log with the trace to the console.

os.Open(`~/pipanel_config.json`)

This will always fail because ~ is not expanded as it ought to be. Consider parsing the home directory from $HOME or other means.

Optionally, set a default brightness for the display upon pitouch DisplayManager initialization. This value should be user-configurable (and disabled by default).

Because of the server implementation, it is possible for multiple alerts events to be passed to an Alerter simultaneously. Therefore, it is necessary to protect the windows field of GTKAlerter with a mutex to avoid race conditions.

Request handlers should complete their task and return control to the server within a certain amount of time, such that the client can receive a response in a timely manner.

If the request takes too long, its context should be canceled and request handlers should stop processing the event.