boyska
ed985a92e9
The idea is that the UI can run in a separate process, so there is now a way for another process to know the state and to display an interface accordingly
37 lines
1,4 KiB
Go
37 lines
1,4 KiB
Go
/*
|
|
Package uiserver creates a server to share an object (readonly) with clients.
|
|
|
|
Background
|
|
|
|
We want to deal with a user interface that is output-only: we only care about
|
|
providing a representation of the internal state to users, not getting their
|
|
input (that is, we'll do that part as a separate component).
|
|
|
|
We also want the UI to be completely detached from the core, ie running as a
|
|
separate process: to do so, bind a socket and exchange informations over it.
|
|
|
|
This is especially reasonable when dealing with "embedded" boards where the
|
|
outputs might be LED or OLED displays and the inputs might be pushbuttons so
|
|
privilege separation is especially needed, but can prove useful in any other
|
|
context.
|
|
|
|
It must be easy to write a UI with a different programming language: to do
|
|
so, gob is excluded, JSON is preferred.
|
|
We assume that the "state" is pretty small, so caring about diffs will only
|
|
be a waste of time.
|
|
|
|
Protocol
|
|
|
|
Bind a socket. Every UI is a client, which connects to our socket.
|
|
Upon connection, send some "hello" just to check versions etcetera. Then
|
|
send a serialization of the complete state. Upon change, just send it all
|
|
again.
|
|
Conversely, the client will read the socket and set the UI according to the
|
|
state that has just been read.
|
|
|
|
Usage
|
|
|
|
The uiserver package implements a generic server specifically designed to
|
|
send updates upon connection and whenever asked to (with NetUI.Update())
|
|
*/
|
|
package uiserver
|