ShoveItHN

A WHAT?

Thanks! I haven't done much network programming.

While this SSE channel stays open, the controlling app will need to be able to continue to do additional traditional GET, POST, etc. calls to the server. How are responses to those distinguished from data coming in from SSE?

Interesting. I'm writing an application that will control devices over HTTP with a REST-style API (defined in OpenAPI). But we also want those devices to be able to alert the controlling application to events without being polled. This won't be a large datastream, but rather the occasional update of progress or notification of a state change.

I was considering Websockets or MQTT (or both), so server-sent events sound like a direct and possibly superior competitor. But from a design standpoint, what do you do? Just do a GET on some general "status" endpoint to open this SSE stream and then have the server send everything down this pipe indefinitely?

Look at your first two sentences. You say MQTT supports authentication like MQTT.

Similar to the Atari's. And they both offered redefinable character sets and fine scrolling, which allowed you to create giant scrolling maps and backgrounds as screenfuls of characters requiring very little memory.

The Commodore's was a bit mushy compared to the Atari 800.

But they both absolutely crushed the quality of almost any keyboard you get on a computer today.

Note the "inverse" and "normal" video keys.

"Normal" means white text on a DARK background. It's sad that it has taken the industry 30 years to remember that.

I agree. Apparently it's just a library, so you have to use it to construct an application.

But they should provide some links to applications built with it.