Push or Pull? Stateless or Stateful?

So Bill says XMPP matters and is "pushing" a push model for message delivery.

Am curious, though, if this debate can be re-framed as Stateless or Stateful? A stateless messaging system would map to a Pull strategy, placing the burden on the client to actively poll or pull its messages. A stateful system would map to Push, where the server maintains a connection for every subscribed client.

Stateful systems are hard to scale over the internet. One reason is because there's a limit to the number of TCP connections I can maintain open at any one time. What's the limit? Not sure, probably OS and configuration specific, but is that a limit that I'll easily hit? If I'm not actively maintaining an open connection, can the system still be called Push?

An aside on Push vs Pull. Push might make for faster reacting systems, but I know that Pull is usually the way I want to process information. The more Push events I have, the less I get done, the less I can focus, and the more transient everything becomes. To get things done, I need to Pull information when I'm good and ready. So even if we've figured out how to scale Push and deploy it everywhere, the edge agents of mine will still buffer everything until I'm ready to Pull it.

So take that, Outlook email notification popups!
Post a Comment

Popular posts from this blog

I ported a JavaScript app to Dart. Here's what I learned.

Converting Array to List in Scala

Minification is not enough, you need tree shaking