I'm no expert in anything, but I think the *only* motivation behind PubSubHubbub was to implement a pub-sub pattern over HTTP, which makes me think there is no "reason" to compare* it with anything that is not 1) a pub-sub, 2) a http based.
* and that doesn't mean that it's not generally/theoretically/practically... better than anything else, it's just the scope. On Fri, Feb 19, 2010 at 9:28 AM, Pedro Melo <[email protected]> wrote: > Hi, > > On Fri, Feb 19, 2010 at 8:11 AM, John Panzer <[email protected]> wrote: > > Another: Spam. > > > > The subscription handshake ensures that subscribers can trivially drop > > stuff they haven't subscribed to. > > As any mailing list software, that does two-step subscription checks. > Even better if you use [email protected] as the only accepted > incoming address, where HASH can be a sha1 of a secret + source > information. > > The problem of spam is lack of authenticated source information. > > But really, if you wanted a push-system over some protocol other than > HTTP, my bet would be on NNTP, not SMTP. Sure, SMTP+IMAP (with IDLE) > would work and even provide the same real-time semantics of PuSH, but > for large number of subscribers, NNTP beats SMTP. > > Bye, > > > > > On Friday, February 19, 2010, ara.t.howard <[email protected]> > wrote: > >>> PuSH is far, far simpler, less likely to be affected by ISP > restrictions, > >> > >> hrm. than email? even a casual reading of this list will show a ton > >> demand to make it more complex: message queues, private subscriptions, > >> authentication schemes, opaque body contents, additive relays, etc. > >> all things part of SMTP/email. it seems unlikely that it will be able > >> to remain as simple as it is if it achieves widespread adoption. > >> > >>> and most importantly, actually exists. As far as I know, the SMTP-based > >>> system you're describing is 100% hypothetical. > >> > >> i'm talking about using simple email and, instead of letting mail > >> spool, configuring 'stdin hooks' instead of 'web hooks' which all mail > >> daemons provide a simple configuration for and every perl programming > >> sysad in the world can administer and understand - because they are > >> already doing it. > >> > >> let me put it another way: > >> > >> what major real world technical advantages does push have over > >> programatic subscription to url-name based mailing lists and > >> configuring programs which read on stdin to receive mail (rather than > >> letting is spool). what major real world dis-advantages would it have > >> compare to such a system. > >> > >> for the record, i've moved a lot of message around the world using > >> this paradigm and have found it to be ultra robust, scalable, simple > >> to write code for, simple to maintain, and simple to debug. i've also > >> maintained many varieties of push based systems and found them to be > >> massively painful in production due to the eventual real world > >> requirement to be aware of network issues on the receiving end - aka > >> retry logic - something which email based systems handle like none > >> other. > >> > >> i guess i really do not understand how a mega successful push system > >> would be technically superior to having a bunch of machines > >> subscribing to email lists and reading email instead of humans doing > >> the reading... > >> > >> in case people are not aware, there is some really interesting > >> application development in this space: http://lamsonproject.org/ > >> > >> > >> regards. > >> > >> > >> > >> > >> -- > >> -a > >> -- > >> be kind whenever possible... it is always possible - h.h. the 14th dalai > lama > >> > > > > -- > > -- > > John Panzer / Google > > [email protected] / abstractioneer.org / @jpanzer > > > > > > -- > Pedro Melo > http://www.simplicidade.org/ > xmpp:[email protected] <xmpp%[email protected]> > mailto:[email protected] >
