FEP-proposal C2S: websocket endpoint

[bobwyman]

@trwnh

websockets are the equivalent of push notifications, right?

WebSockets do allow push notifications to be implemented, but the fact they are bi-directional connections allows them to do more than just that. On the other hand, ServerSentEvents, because they are uni-directional, are “just” push notifications.

@trwnh

it seems to be unnecessarily replicating standard activitypub flows for no discernible benefit

Well, I think there is a benefit to using an existing WebSocket connection to push data from the client to the server – especially if you’ve already created the connection to receive server-to-client events. Reusing the existing connection will result in some reduced resource consumption by the server. The server won’t have to create and tear-down an HTTP connection for each item pushed to it and it won’t have to repeat authentication/authorization work for an already established connection. That may not be a lot, but it isn’t nothing.

While it would take a little bit more code to support client-to-server over an existing WebSocket, it seems to me that the amount of additional code is really minimal. The server’s HTTP and WebSockets interfaces could both be very thin and dispatch to the same code to actually do stuff with any data received from the client. (Note: I assume that most, if not all, servers that implement either WebSockets or ServerSentEvents would usually implement the default HTTP methods as well in order to ensure support for older or less flexible clients.)

It also seems to me that standard protocol libraries would probably be implemented so that the use of HTTP or WebSockets was largely, if not completely, hidden from client implementers. At most a developer might be asked to say which transport to prefer, but, I assume that it might also be reasonable to say to the library: “Do what works best…” and have the library figure out which transport to use and when to use it. Why isn’t that a reasonable assumption?

Given that there are, at least, some benefits to using WebSockets for client-to-server, and given that the server-side implementation cost is pretty low and might even be hidden from client developers, I can’t see why one wouldn’t at least allow using WebSockets for client-to-server communication as well as for server-to-client. Of course, if it is allowed, then it must be specified.

[bobwyman]

@nutomic

It seems like this problem could be solved much easier by using HTTP long polling

The problem with long polling is pretty obvious and described in the document you linked to. While long-polling can reduce the latency in sending messages from server-to-client, every time a message is sent the connection is closed and must be re-established by the client. Also, long-polling HTTP connections time-out fairly quickly. So, you end up with a constant buzz of new HTTP connections begin established for clients that aren’t otherwise seeing any new data. While this is “good,” since it can result in fewer connections/hour than with a simpler short-polling solution, its still polling and it is still unnecessarily wasteful.

Handling problems that occur due to the gap between one long-polling connection being closed and a new one replacing it can introduce all sorts of subtle complexities that are a real nuisance to deal with. (Note: I had a great deal of experience with long-polling solutions when working on PubSub.com back in the early 2000’s. I wouldn’t recommend long-polling to anyone if an alternative exists such as WebSockets or ServerSentEvents.)

One improvement on long-polling is to implement streaming and thus allow the server to send multiple messages over a single connection, however, all HTTP connections will time-out after a fairly short period of time and that means you’ve got to have code to detect and re-establish dead connections. But, why bother with that complexity? You might as well just use WebSockets or ServerSentEvents instead of reinventing what is a pretty standard mechanism that offers very few opportunities to be usefully creative.