4 ms·
> All communication over HTTP / HTTPS Why HTTP? And, for example, not BEEP? HTTP can't handle multiple concurrent logical streams, thus can provide you with on
by drdaeman 15y ago
> All communication over HTTP / HTTPS
Why HTTP? And, for example, not BEEP? HTTP can't handle multiple concurrent logical streams, thus can provide you with one resource per connection at a time. Every separate HTTP (and HTTPS) connection requires a TCP (and TLS) handshake, re-authentication and so on.
Also, long-polling is a hack, born because of HTTP limitations. Is there any reason to do long-polling when you can just send a signal over bidirectional connection?
This could be a unpopular opinion (lots of web developers out there), but I believe, while it is perfectly possible to use HTTP, it is just plain ugly for such job.
> Stateless
Is wrong for protocols where you require a state (authentication, folder/label subscription and so on). How many stateless pub-sub protocols you know about? Be it lightweight Redis Pub/Sub or XML-bloated AMQP and XMPP - they're all stateful for a reason.
HTTP cookies do represent state. You're just taking a shortcut by re-authentication with a session token. The state you keep could be only auth data (so you'll end up re-sending, for example, what labels you're interested in every time), but it's still a state.