Ah thanks that makes sense. I didn't see it when I glimpsed over the site.
That should provides reliable framing on both sides. But as shown in the linked it page it also comes with the downside of not being able to send raw websocket messages which contain a new line - so it's not possible to port existing applications from other websocket servers to this one without having to change communication.
I don't understand why the daemon needs to client to escape newlines in the message. Can't it handle that before feeding the message to STDIN?
For example, my browser sends:
This is line one...
...and this is line two
as a string ("This is line one...\n...and this is line two") and the websocketd receives that, and passes along
This is line one...\\n...andthis is line two\n
to the STDIN.
It knows that the message is one thing, so the newlines aren't the same as the end of message, right?
It'd also be nice to use EOF as the indicator to flush STDOUT to the client, so the program can also emit newlines without needing to escape them first.
All that being said, this is nifty. I think I can use this for some low-volume ideas I have on an internal app. The newline handling isn't a problem because I'm not replacing anything that already exists.
> It'd also be nice to use EOF as the indicator to flush STDOUT to the client, so the program can also emit newlines without needing to escape them first.
EOF is not an actual control code though (and is implementation dependent). However there are control codes for message framing e.g. ETB, ETX, EOT (often used as terminal EOF), FF (form feed / page break), RS/GS/FS
That should provides reliable framing on both sides. But as shown in the linked it page it also comes with the downside of not being able to send raw websocket messages which contain a new line - so it's not possible to port existing applications from other websocket servers to this one without having to change communication.