| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Wildly known to be broken.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
And batch event messages together as much as possible.
JSON has proven itself to be really slow
(for example, encoding/json.Marshaler is a slow interface),
and browsers have significant overhead per WS message.
Commands are still sent as JSON, sending them in binary
would be a laborious rewrite without measurable merits.
The xP server now only prints debug output when requested,
because that was another source of major slowdowns.
|
| | |
|
| |
|
|
|
| |
For non-trivial types, which are expensive to serialize
with encoding/json's struct reflection.
|
| |
|
|
|
| |
Still trying to make the frontend load tolerably fast,
still unsuccessfully.
|
| |
|
|
|
| |
Compression happens to be broken in Safari,
though luckily there are friendlier browsers one can use.
|
| |
|
|
| |
The left column used to jump around, and phones were near-unusable.
|
| |
|
|
| |
For reverse proxies.
|
| | |
|
|
|
For this, we needed a wire protocol. After surveying available options,
it was decided to implement an XDR-like protocol code generator
in portable AWK. It now has two backends, per each of:
- xF, the X11 frontend, is in C, and is meant to be the primary
user interface in the future.
- xP, the web frontend, relies on a protocol proxy written in Go,
and is meant for use on-the-go (no pun intended).
They are very much work-in-progress proofs of concept right now,
and the relay protocol is certain to change.
|
