Prototype said:
But it can be beneficial to use proven backend technology that is known to reliably handle hundreds of connections and provide persistency out of the box.
Ah, you're talking about connections between the backend and database… I just got that. I thought you were referring to connections from browsers, in which case you'd need to elaborate on the handling of hundreds of connections. I think we're on the same page now?
I'm afraid I need to elaborate ? HTTP requests have the advantage of being stateless, which means you don't have to do any bookkeeping on who's connected. Even your server may go down temporarily without consequence. This concept is much easier to implement and more fault-tolerant than keeping all the balls in the air within a single process IMO. Especially in a scenario where everybody has to wait for his turn anyway.
Prototype said:
But it can be beneficial to use proven backend technology that is known to reliably handle hundreds of connections and provide persistency out of the box.
Right - this isn't http, which you've also explained afterwards.
Prototype said:
I'm afraid I need to elaborate ? HTTP requests have the advantage of being stateless, which means you don't have to do any bookkeeping on who's connected.
A terminology thing - exactly why I thought you weren't talking about the browser clients any more. But you're of course referring to how easy it would be with exchanging messages in a stateless manner.
Come the time that @spartan123 needs to apply security and negotiate who is who, it becomes less relevant, IMO, because they need to rig some sort of authorization and register clients on sessions anyways.
