Newsgroups: news:comp.mail.imap Mailing-List: [EMAIL PROTECTED] Followup-to: news:comp.mail.imap ------------------------------------
Deflecting protocols and formats is today one of the aim of the Internet Community. Proxies and gateways are commonly used for deflexion:
- Mail-to-NNTP www.gmane.org e.g., - NNTP-to-IMAP http://asg.web.cmu.edu/cyrus/download/imapd/ e.g., - NNTP-to-Mail http://news2mail.com e.g., - RSS-to-IMAP/Mail http://rss.blogstreet.com e.g. - iCal-to-RSS http://ical2rss.bzzt.net/ical2rss.html e.g., - RSS-to-iCal http://www.codent.com/rss/rss2ical.php e.g., - FTP-to-IMAP <imap://ftp.cac.washington.edu>, - Atom-over-XMPP and Atom/RSS-to-XMPP http://rss2jabber.berlios.de e.g, - Mail-to-RSS http://dodgeit.com/ e.g, - RSS-to-NNTP: http://www.methodize.org/nntprss/ e.g., - etc...
1. I have been thinking to the idea of IRC/Chat-over-IMAP and I try to formulate so that it can be concrete.
IRC/Chat-over-IMAP would work on the base of (asynchronous) *incremental* and *partial updates* thanks to the IDLE command. But I don't know if a mail structure could allow this. Are there unsurmontable constraints ?
Could the _incremental and partial update_ become a part of the IDLE command ?
Unless a kind of XMPP-over-IMAP would make a sense ?
2. Also, I have been thinking to the concept of intertwingling IMAP and Atom/RSS. I find it a damn good idea. Maybe Atom could become consubtantial to IMAP ?
Just imagine: when you create a mailbox the client propose you as an option to include a RSS/Atom link. The IMAP server would become an aggregator and a cache where cached copies of RSS feeds could be stored.
Some people may say it does not make a sense and those ideas are just heresies - and Thunderbird 0.8 is enough since it is an Atom/RSS aggregator - or use http://fusemail.com.
But look: for few weeks now there is a "mediatic" discussion about bandwidth usage cost and RSS feeds retrieval. Publishers are fed up with abusive feeds retrievals.
This is basically because Atom/RSS publishing is based on a *pull* delivery model even if the implementation of the "RFC 3229: Delta Encoding in HTTP" http://www.ietf.org/rfc/rfc3229.txt seems to solve partially this problem as suggested by Bob Wyman http://bobwyman.pubsub.com/main/2004/09/implementations.html e.g.
Also there's an interesting article of Bill de Ohara "WWW cubed: syndication and scale" http://www.dehora.net/journal/2004/09/www_cubed_syndication_and_scale.html in which he explores ideas which would solve the pull delivery model problem of Atom and RSS publishing. He talks about alternative ways for Atom/RSS feeds retrievals: NNTP, Bittorrent and XMPP but not talk about IMAP - royally ignored...
When I read the abstract of the "RFC 2177: IMAP4 IDLE COMMAND", http://www.ietf.org/rfc/rfc2177.txt it convince me the IDLE command is the solution for RSS/Atom feeds retrieval:
-----------------------------Excerpt---------------------------------- "The Internet Message Access Protocol [IMAP4] requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It's often more desirable to have the *server transmit updates* to the client *in real time*. This allows a user to see new mail immediately. It also *helps some real-time applications based on IMAP*, which might otherwise *need to poll extremely often* (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can't expect this behaviour and must poll.)" --------------------------End-of-excerpt------------------------------
But the IMAP IDLE command is for "applications based on IMAP" and Atom/RSS seems to be based on HTTP only.
Peter Saint-Andre writes in "Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP) - draft-saintandre-atompub-notify-01" http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-01.txt
-----------------------------Excerpt---------------------------------- "Content syndication follows a classic "observer" or "publish-subscribe" design pattern: a person or application publishes information to a "channel", and an event notification (or the data itself) is broadcasted to all those who are interested in knowing when information is published or modified for that channel. On the Internet today, publication of periodically-updated resources is handled by means of standard technologies such as [HTTP], and *it is not envisioned* that this will change since [ATOM-PROTOCOL] specifies the use of HTTP for publication. However, existing methods for learning that a resource has been updated are currently *limited to "polling" for changes via HTTP*, which is *inherently inefficient*. What is needed is a technology that can be relied on to *push information* only when a resource undergoes a state change, and only to those who are interested in learning about such state changes". --------------------------End-of-excerpt------------------------------
So if it is "envisioned" that the Atom Protocol could specifie the use of IMAP for publication, maybe Atom-over-IMAP with incremental and partial updates would make a sense and become a part of the IMAP paradigm ?
Thus,
- it would be possible to subscribe to Atom/RSS feeds directly when creating a mailbox; - feeds could be "incremental[ly]" and partially updated in real-time thanks to the IDLE command; the 'Modified since' annotation could be useful for feed updates; - it would encourage the Atom/RSS Community to develop a push delivery model for Atom/RSS publishing if IMAP servers could store cached copies of Atom/RSS feeds.
As Jerry Wind and Colin Crook wrote in their book "The Power of Impossible Thinking":
"Sometimes you need to _destroy your old model of thinking_ to make space to see a new one. "What would happen if you set aside your current model? Without the burden of these ‘legacy systems,’ what could you create in their place?” http://www.innovationtools.com/Weblog/innovationblog-detail.asp?ArticleID=540
May a new model could be created ?
-- kael
http://del.icio.us/ubi.quito.us
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
