In my initial post concerning Erlang, I neglected to mention a couple other reasons I think it might be a big help.
These are: messaging middleware via RabbitMQ, and CouchDB. I read a few of the discussions concerning the (possible non-)availability of an intended email recipient, the last one mentioned UUCP, i.e., having the message 'hop' closer and closer to its intended recipient. IIRC, uucp was developed during the very early arpanet days, when inter-machine links were more down than up, and the chances for a complete, direct path from machine to machine at any given point in time were slim, so such 'hopping' of a message closer and closer made sense. Today's networks are different though I think -- when a machine is on there is almost certainly a complete path to it available, i.e., no down links. But the initial question was: what happens when the recipient's machine is not available? I'm thinking that message queues on the source machine might help deal with this. When a recipient's mail delivery agent is not available, the message is place in an 'outgoing' queue. If the recipient/contact is part of the FBx network, i.e., running the FBx suite, goes offline and then comes back online, and we (the sender) are in its contact list, then *it* should contact *us* for messages it might have missed. If the recipient is not in our contact list or is but not participating in the FBx network, then as per current industry practice, periodically our messaging system/mail transport agent should re-attempt delivery, etc. This addresses the intermediate storage issue. Further, ideally it would be encrypted with the public key of the recipient, which I think would prevent even the sender from reading it. Additionally, IINM, RabbitMQ implements the STOMP protocol, used by 'Pubsubhubbub', the underlying mechanism for Google Reader and other 'publish/subscribe' systems, including some OpenSocial implementations, I think. IIUC, when one subscribes to feed, one provides a 'callback' address, where the publisher can send the content when something new becomes available. This efficiently provides 'push' publishing to interested parties. This seems very useful to me. CouchDB I'm not too familiar with (yet). But its got a very good pedigree -- a Lotus Notes developer left IBM and self-funded it for 2 years in order to create a database designed for the 'web'. Stores data in JSON, for starters. My point being CouchDB, while not needed at present, is another option made available by using Erlang. So short-term and long-term, i.e., strategically, an investment in Erlang would seem very useful to a project of this sort. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
