On Thu, Feb 18, 2010 at 11:00 PM, ara.t.howard <[email protected]> wrote: > "in what significant way is the protocol superior > to intelligent use of SMTP with filters"
SMTP and PSHB implement fundamentally different message routing patterns. SMTP <http://www.ietf.org/rfc/rfc5321.txt> defines a method of implementing "sender controlled" message routing while PSHB defines a method of "recipient controlled" message routing. In a sender-controlled system, whether a message reaches a particular node in the network is determined exclusively by message routing information attached to the message by the sender of the message. This implies, of course, that the sender of the message must know each of the eventual recipients of each message or at least proxies for those recipients (a "proxy" in this case would include things like mailing-list inboxes that then do further sender-controlled distribution of the message.) On the other hand, in such a sender-controlled system, the potential recipients of messages have no means of discovering the set of all senders who might send them messages. Also, recipients have no means of controlling the rate, flow, or content of messages received. PubSubHubbub (PSHB) as a "PubSub" or publish/subscribe system implements a recipient-controlled method of message routing. In such a system, the publisher only controls whether or not a message is available for routing, not which endpoints or even if any endpoints actually receive the message. In a PSHB system, who receives a message is determined exclusively by the recipients themselves. Publishers of messages have no means to determine who the recipients are. (Note: This isolation of publishers from subscribers is one of the key reasons that PubSub systems, in general, are much less subject to "spam" than sender-controlled systems. While SMTP is not intended to provide direct support for recipient-based routing, because it defines only a means for transferring data between nodes in a network, it could certainly be used as one part of the message distribution mechanism of a PubSub-based system. The core of a PubSub system used SMTP would, of course, be a component that was able to collect and manage "subscriptions" or "routing requests" from recipients. That component would then drive the addressing of SMTP messages according to the request of recipients. To a certain extent, this is what is done by the remailers that are the core of most mailing list systems. It is important to realize, however, that in such a system, SMTP would simply be used as a message transport mechanism and really provides little unique value that couldn't be provided many other ways. As mentioned before, the meat of such a system is not in message transfer, it is in the subscription management which is required to properly manage message routing decisions. If you're looking for protocols that should be considered as alternatives to PSHB, you'd probably do better to look at NNTP<http://www.ietf.org/rfc/rfc3977.txt> (Network News Transfer Protocol) rather than SMTP. However, it is important to realize that in most applications, even though NNTP based systems appear to be "pushing" data, this is only appearance. What is really going on in most cases is that down-stream servers are polling up-stream servers for data. (I will refrain from a multi-page digression into the evils of polling...) Additionally, it is important to understand that the NNTP protocol is not particularly well suited to handle the case of hundreds of millions of "groups." Much of NNTP consists of commands to list and get metadata about the supported groups or articles in groups. That stuff just isn't reasonable to provide when you've got hundreds of millions of items in the database... A better protocol than NNTP would be XMPP<http://www.ietf.org/rfc/rfc3920.txt>. This is particularly the case if you were to implement the XEP-0060<http://xmpp.org/extensions/xep-0060.html>Publish Subscribe protocol extension to XMPP. This would give you a true "push" protocol with subscription management and everything else you need. However, you would discover that a simple implementation of XEP-0060 would give you pretty much what you have with PSHB today. You'd also discover that it was massively harder to get anyone to support what you had done since XMPP relies on continuous connections between servers and doesn't layer on top of HTTP they virtually all other "modern" protocols do. Yes, you'd be able to make all sorts of well-reasoned arguments claiming that such a system would be "better..." (I've been making those arguments for years!) But, it wouldn't do you much good. The ugly reality is that a system that is implemented is better than one that isn't and while we're slowly getting people more and more comfortable with XMPP (especially since Google AppEngine makes it so easy to use), most developers today simply aren't comfortable or able (because of ISP limits or access control issues) to develop non-HTTP interfaces. PSHB isn't a protocol casually designed without consideration of the alternatives. I'm sure that if SMTP, NNTP, XMPP, etc. was actually better suited to the task, then PSHB wouldn't be defined the way it is today. I have personal experience implementing and using all of the protocols defined here and frankly, I'm quite happy to see that PSHB has been able to do in a very short period of time something that many of us in this business have been trying to get done for a very, very long time. bob wyman On Thu, Feb 18, 2010 at 11:00 PM, ara.t.howard <[email protected]>wrote: > hey yall- > > at the request of brett i'm dumping this question > > http://twitter.com/drawohara/statuses/9290810768 > > http://twitter.com/drawohara/statuses/9291994197 > > etc. > > onto the list for discussion > > summary: > > "in what significant way is the protocol superior to intelligent > use of SMTP with filters" > > regards. > > -a >
