Hacker News Reader

Comment by lexicality | Hacker News Reader

Feels like a bit silly not to have made this compatible with SSE since all the mechanisms for acessing that are built into browsers these days.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://html.spec.whatwg.org/multipage/server-sent-events.ht...

View on HN

> "Feels like a bit silly not to have made this compatible with SSE ..."

The feedback is great, and valid. I wish it could have been expressed less dismissively though.

Depending on the culture you are living in, this can be perceived as either dismissive or respectful.

I was curious enough to browse through the comments of @lexicality to conclude that he is European, so there is a chance that you were considered capable of receiving a direct feedback.

That is, by giving direct feedback, @lexicality showed you respect.

The feedback isn't to me.

Also, I live in northern Europe. Generally feedback is direct, but respectful. Calling something silly is usually (but not always) out of bounds. European-style feedback might be: "I'm surprised you did not use X because it perfectly matches your use case."

Or "Great feedback but I wish it could have been expressed less dismissively"

You know, this might not apply here but lemme contribute this:

Recently at my place of work we were required to take some diversity training. In this training we learned about high context and low context regional and familial cultures. High context individuals convey and respond to indirect details and nuance, while low context cultures are more direct with what they receive and convey.

Learning this helped me a lot and I notice these differences often, as I too come from a different cultural background than my team mates.

I don't understand. Does the diversity training teach you to treat people differently based on where you think they came from?

It teaches you that if you are a high context individual receiving low context feedback to try and negate your frustration by understanding the possible factors influencing the response you received before letting it be a blocker in your interactions, also the inverse.

I think it's more similar to learning to speak somebody else's language and not get lost in translation.

Less this and more that one should be cognizant of their own inherent communication biases.

I've seen these skills described as CQ (Cultural Intelligence), distinct from EQ or IQ. IMHO, it's the 3rd leg of the stool for effective intelligence in any non-solo endeavor.

I hadn't heard those terms before, thanks. I'll check those out.

A couple things:

A) People have vastly different (even abusive) forms of communications. What works for one group does not work for another. "Sensitivity training" does not account for this, in fact it causes issues.

B) EQ and CQ are made up terms, but more importantly they aren't realistic. IQ, also is somewhat made up, its used as a sort of "general intelligence" marker and it is that in the context of broad studies, not so much on the individual level. IQ has been long used to browbeat certain ethnic groups, these new "made up" terms are similar, in that people are using them to browbeat various groups, in attempt to put themselves on a higher "moral ground". Its disgusting, and insensitive nonsense. They don't exist, and we don't have the bandwidth to all just "conform". And no, thanks I don't take kindly to being brainwashed.

This is interesting, thanks for mentioning. I wonder what the learning from that is though? Like, if you notice the difference, do you adapt to the other style? I feel like I can do that, but it also feels weird and "not me".

It's more about addressing ways out of social conflicts due to misunderstanding context. Both sides can mean well but a mismatch in speech patterns can cause undue conflict. Understanding these differences gives you an "out" from those negative feelings.

Part of learning to be an adult - growing thicker skin, a backbone, and ALSO understanding that everyone is different, learning to navigate that rather than just get frustrated or upset like you are two-year-old.

Just wanted to add that as a rule of thumb, Western cultures tend to be low-context, while Eastern cultures tend to be high-context.

This also ties in indirectly to punctuality of cultures I think. Lower context cultures tend to be punctual.

And I've felt the Eastern cultures are becoming lower context due to doing business with the West. This may or may not be a good thing.

PS: I'm from a high context culture, but I've lived in America for a while before returning back to my home country. Ever since, I've felt like something was off.

"silly" is used a little more casually stateside, it's actually more of a light touch descriptor

I believe the HN guidelines actually say something about this, but either way: I think there is tremendous value in interpreting other people's statements as charitably as possible.

Why take offense when none may have been intended?

At least where I come from (Ireland, but I'd say it's the same in the UK where Lexicality is from), "silly" and "stupid" are distinct. You can describe something like this as "silly" perfectly respectfully, but describing it as "stupid" would be out of bounds.

I don't agree that this instance is among the kind that can "be perceived as respectful" - I think we can make space to acknowledge that that is a thing, and that nevertheless this is not an instance of respectfully direct communication. So that's a red herring.

Moreover I don't see that "being European" has anything to do with anything, and classifying someone as either being "capable of" or not "capable of" receiving direct feedback, far from respectful, is an instance of insulting with plausible deniability, which is perhaps the most practiced art form of internet comment sections.

Calling something silly is not direct, nor respectful.

Perhaps your view of communication with Europeans is influenced by other factors that's led you to this conclusion? (or to put it respectfully, silly)

For me atleast as an Australian this would not be considered even remotely disrespectful.

First, it's addressing the idea rather than the person.

Secondly silly isn't used to convey an idea being bad, stupid or otherwise without merit.

The way I read this is that "I think this should address why it's not built on SSE or perhaps should be redefined to be built on SSE", silly just does that with much less words.

"Silly" also conveys the feeling that it's probably too late to redefine this as SSE.

I am reading all the replies and thinking the word silly seems to convey a different thing to different people. At least in the British context it is extremely mild.

But somehow others read it as like you said "being bad, stupid or otherwise without merit."

Yeah I'm honestly surprised too, but I'm Australian so effectively British for all intents and purposes when it comes to what language we find offensive (i.e very little lol).

Do you find it easy to find great, honest, and valid feedback on the internet?

How much of the supply of great, honest, and valid feedback would you sacrifice in order to make the supply that remains use "less dismissive"[0] language like "a bit silly"?

[0] Less dismissive in quotes because I do not find that language dismissive in the slightest

Let's chalk it up to cultural difference! Some commenters think "silly" is fine (Ireland, UK, US - although I'm from the US and I disagree, but let's grant it). Some think it's not.

Let's assume that "silly" was meant kindly and not dismissively!

This reminds me of CometD - https://github.com/cometd/cometd. Is it same in concept?

Had never heard of SSE before. Followed the link and found this warning:

> Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

This is the first time I’ve heard of per-domain connection limits. Seems… not great? Doesn’t this turn into a client side DoS? User opens 6+1 tabs and now the browser has exhausted all HTTP connections to your domain serving SSE connections?

I’ve used long polling before, I don’t understand how I’ve never observed the connection limit of 6…

Perhaps we should define a new HTTP header for servers to say: "It's ok for clients to initiate N connections with me" so that we can write web apps without this restriction.

...or we just keep moving to http/2 which avoids this limit.

That'd be great, but is a lot harder than adding a header. HTTP/2 changes the entire wire format into a binary protocol that multiplexes multiple streams over a single connection. It's a lot harder to implement than HTTP/1, which you can type out manually over telnet:

    telnet news.ycombinator.com 80

    GET / HTTP/1.1
    Host: news.ycombinator.com
    \n
    \n

Adding a header could be as simple as:

    HTTP/1.1 200 OK
    Content-Type: text/html; charset=utf-8
    Multiple-Subscriptions: OK

The limit applied only to browsers which have all implemented HTTP/2 at this point.

Yes, the limit is implemented in browsers, but it's for the protection of servers. The idea is to prevent a web app from DDOSSing a server somewhere.

This is especially a problem for servers implemented with one thread or process per connection, rather than an async event queue like nodejs, because each thread takes up a few megabytes of memory, and if a browser opens 1000 connections, that's 2 gigs of memory right there.

But if a server is implemented properly to support long-lived connections (by using node, or greenlets, or other async system) then it should be able to opt out of that browser protection. A standardized header would allow a server to opt out of it.

> I don’t understand how I’ve never observed the connection limit of 6…

Practically speaking this limitation has been obsolete for 5 years or so. With HTTP/1.1 there used to be ways to achieve more parallel downloads through domain sharding [1] on the server side and browser tweaks [2] on the client side.

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Domain_sha...

[2]: http://kb.mozillazine.org/Network.http.max-persistent-connec...

This limit was(/is) actually a common problem with HTTP/1.1, and was one of the motivations for HTTP/2. A common workaround is "domain sharding"[1] where you would split your site up between several domains, so that you could get more concurrent connections. Which is important for improving page load time, but doesn't really help with having SSE for multiple tabs (unless you do something crazy like using a randomly generated domain for each SSE connection).

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Domain_sha...

Hi! I am the author of http-feeds.org. Thank you for your feedback.

For this spec I aimed to keep it as simple as possible. And plain polling-based JSON Endpoints are the most simple and robust endpoints IMHO.

If you need, you could implement an SSE representation on the server endpoint by prober content negotiation.

The main reason, why I dropped SSE it the lack of proper back pressure, i.e. what happens when a consumes slower than the server produces messages. Plus, it is quite hard to debug SSE connections, e. g. no support by Postman and other dev tools. And long lasting HTTP connections are still a problem in todays infrastructure. E. g. there is currently no support for SSE endpoints in Digital Ocean App Platform, and I am not sure about them in Google Cloud Run.

Overall, plain GET endpoints felt much simpler.

Thank you for writing this great spec up for others to use!

I think totally right that back-pressure and plain GETs are an important use-case to support, and am really happy to see a beautiful spec written up to articulate concretely how to support them.

It is also great to be able to switch amongst these methods of subscription, for instance, if your server can keep a persistent connection open, it's nice to be able to get realtime updates over a single channel, but to still be able to fall back to polling or long-polling if you can't. And if you switch between a polling and a subscription, it's nice if you don't have to change the entire protocol — but can just change the subscription method.

There's a growing effort to integrate all our various subscription-over-http protocols into an IETF HTTP standard, that we can use for all these use-cases: https://lists.w3.org/Archives/Public/ietf-http-wg/2022JanMar...

Maybe you'd be interested in incorporating your experience, use-cases, and design decisions into that effort? We have been talking about starting at this November's IETF. [1]

For instance, you can do polling over the Braid protocol [2] with a sequence of GETs, where you specify the version you are coming from in the Parents: header:

    GET /foo
    Parents: "1"

    GET /foo
    Parents: "2"

    GET /foo
    Parents: "3"

Each response would include the next version.

And you can get back-pressure over Braid by disconnecting a subscription when your client gets overwhelmed, and then reconnecting again later on with a new Parents: header:

    GET /foo
    Subscribe: true
    Parents: "3"

    ..25 of updates flow back to the client..

    **client disconnects**

Now the client can reconnect whenever it's ready for new data:

    GET /foo
    Subscribe: true
    Parents: "28"

Or if it wants to re-fetch an old version, it can simply ask for it via the version ID it got:

    GET /foo
    Version: "14"

And if the source for these updates is a git repository, we could use a SHA hash for the version instead of an integer:

    GET /foo
    Version: "eac8eb8cb2f21c5e79c305c738aa8a8171391b36"
    Parents: "8f8bfc8ea356d929135d5c3f8cb891031d1539bd"

There's a magical universality to the basic concepts at play here!

[1] https://www.ietf.org/how/meetings/115/

[2] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

I'm not entirely sure what you mean by this. SSEs are just normal GET requests with a custom header and some formal logic around retries. I've even implemented them manually with PHP using the `retry` command to mean I don't need to have the connection open for longer than a normal pageload.

> The main reason, why I dropped SSE it the lack of proper back pressure, i.e. what happens when a consumes slower than the server produces messages.

Could you point me to where the spec handles this please? As far as I can tell it has the same problem of the server needing to buffer events until the client next connects

Yeah, we're also pushing for SSE for this kind of things.

Having a standard for what events look like is a decent idea as people generally just make some random thing up without thinking too hard and having a standard is generally helpful - but making your own polling system etc when there's already a battle tested one available seems like wasted effort and a bit counterproductive

Does SSE work reliably in mobile browsers nowadays? A few years back when I tried, it was working OK in Chrome for Android but mobile browser support didn't seem complete.

Sadly, there are very few mobile browsers that aren't Chrome or Safari. In fact, Safari/Webkit is the only mobile browser engine available on IOS at all -- all other browsers are just chrome (pun intended) around IOS webkit.

To your point, https://caniuse.com/eventsource

Also there are polyfills for very old browsers like IE.

I had previously used SSE in a project and had no idea it existed or that it was widely supported by most browsers. It's a beautiful and straightforward technology, but it doesn't seem to be as widely used as it should be, and more tooling is required. Also more tooling is required.

100% onboard with better tooling.

Starting with out of the box swagger support: https://github.com/OAI/OpenAPI-Specification/issues/396

Shame they are not interested in adding it.

The really huge issue with SSE, and the reason why it’s historically been dismissed, is that it us subject to (and counts towards) the HTTP 1.1 domain connection limit.

Sadly that makes it a bit of a pain in the ass to manage for sites served as (/ compatible with) http 1.1.

I know SSE works on scenarios with few or no state updates, like in dashboard UI's. What about other cases where they deal with input data? like in a chat/game

That’s the beauty, the client just do a normal HTTP request. It really simplify the system.

Reply on news.ycombinator.com