RESTfulness is a red herring. It is not lack of "RESTfulness" that
makes IMAP suck. It is that it is a complex and inspecific protocol
with laborious requirements on the server that are better reserved for
the client (such as N level mime parsing where N > 1).
Also POLL is not necessarily lighter way than PUSH. In fact PUSH
probably should be the default behavior and this is easily achievable in
a lightweight manner using HTTP 1.1 persistent connections. A proper
protocol implemented on top of HTTP would scale nicely as existing load
balancers and routers know how to aggregate these 100 persistent
connections into a bout 1.
100 CLIENTS -----100 PERSISTENT CONNECTIONS->LOADBALANCER----1
PERSISTENT CONNECTION--->MAIL SERVER
100 clients with persistent connections in a "keep-alive" state would
consume next to no resources on the mail server. Thus POLL vs PUSH is
of questionable importance. If you have PUSH you should have strong
specs to fall back to PUSH (IMAP doesn't) but from a performance
perspective it is of very marginal importance on the right infrastructure.
ATOM/RSS is also of little importance. That is the equivalent of the
LIST (POP) or FETCH HEADERS commands (IMAP) and thus is only a very
small part of what is needed.
-----Ursprüngliche Nachricht-----
Von: robert burrell donkin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 27. Januar 2007 12:37
An: James Developers List; Serge Knystautas
Betreff: RESTful email [WAS Re: MailboxManager API and session
orientation was: Jsieve Configuration]
On 1/25/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]>
wrote:
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
<snip>
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are asynchronous. I would presume this is
why
someone like Andy will question the larger scalability of the
protocol
given its complexity and how the asynchronous nature of rich email
is
built right into the protocol instead of having the client create
multiple HTTP connections in a REST style.
not just Andy :-)
there are quite a few of us, now...
IMAP is broken. a new RESTful protocol is needed.
an advanced server capable of supporting both a next generation
protocol and IMAP would be very cool
Yes, but... my company's new IMAP server provider supports the IDLE
command, so I get alerted immediately when a new email arrives
(http://email.about.com/od/emailbehindthescenes/g/imap_idle.htm). I
did a test from my gmail account last night... I swear 0.2 seconds
after I clicked "send", Thunderbird dinged and showed the newly
arrived message. I almost thought it was an error message as I had
barely started moving my hand away from the keyboard.
Ok, so it's not the killer app for email, but you would lose features
like that if you moved to a RESTful protocol AFAICT.
yes, you'd lose server push but a web feed (RSS or atom) for email
would work adequately. it would also allow email to be more easily
federated.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
!EXCUBATOR:1,45bb396239413124693792!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
REAL Open Source Groupware without the suck
Buni Meldware Communication Suite
IMAP, POP, SMTP, Calendaring, Webmail, ease of configuration/administration
http://buni.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
