I wanted to mention MQTT (mqtt.org) as good lightweight protocol that has many implementations.
I was surprised author made no mention of it (mqtt.org) but come to think of it it might be because author is specifically looking for queues it seems and MQTT works better as a PubSub, and its durability story which seems the main focus of the author is way different with very cool features - QoS - for delivery reliability but still not a classic queue
My strategy was to start out by implementing the underlying storage primitives first, and then look into which transport to implement later. The transport of course can have a large impact on the required storage primitives, but in my case I built it the other way around since I knew what primitives I would need in my applications.
I've been playing with the thought of implementing (parts of) the Kafka API, but I honestly haven't considered the transport that much yet :)
Reading, 'ensuring that data is actually written and stays written is rather difficult', immediately reminded me of https://github.com/microsoft/FASTER (its not written in Go though), which is basically dealing with just that outlet ( except I think the KV store might be ram heavy, been a bit since I last looked at it )
I'll second NATS. It's "doing a bit too much" these days by also having an object system in addition to durable messaging queues, but it's otherwise a really great little service.
Yeah, it's currently a one-process-army so consensus isn't a problem :D
With the current implementation you /could/ run multiple readers at the same time; the only state there is, is files in S3. But it's a feature that just kinda happens to fall out of the current implementation, and not something it was designed for :)
Not sure about parent, but for me it simply doesn't fit into screen, and the scrolling is explicitly disabled, as well as zooming. Cannot even guess why.
Text runs off the right side of the screen, and you can neither pan nor zoom to get around that.
I don't understand the smile on this question.
It is inconsiderate and broken to block the normal default client automatic text flowing and client controls like that. And you have to go out of your way to do it. The browser will fill the viewport automatically and correctly, if you don't go out of your way to break it. And then it's just extra class act to also prevent the user from overcoming that breakage by panning or zooming. That's chefs kiss right there.
Does that answer your inexplicably smiley question?
Hehe, I'm very sorry, but there must be some kind of cultural barrier here. My smiley was intended as a way to intentionally show OP that I wasn't trying to be mean or anything, but sincerely asking the question :)
Anyway, it's my post. I just pulled down a Jekyll theme that I thought looked nice and tried it on my laptop and phone (where it worked fine). But thanks, I'll try to look into how and why it's broken.
The cultural disconnect is to me the smiley in that context indicated you didn't believe there was actually any problem and assumed there would be no valid answer to the question, and the question was insincere.
Very cynical and probably at least partly the result of projection, and I do now believe your sincerity, so I am only explaining equally sincerely now, not criticizing.
I was surprised author made no mention of it (mqtt.org) but come to think of it it might be because author is specifically looking for queues it seems and MQTT works better as a PubSub, and its durability story which seems the main focus of the author is way different with very cool features - QoS - for delivery reliability but still not a classic queue