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] mailto:[email protected]
