On 1/28/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
RESTfulness is a red herring.

not so much a red herring as an orthogonal kipper ;-)

yes, i admit i used a lie of juxaposition

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).

+1

IMAP is just a plain bad protocol

and yes, it would be possible to create a better IMAP but the point
is: why bother?

i'm more interested in an alternative protocol which can be layered on HTTP

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.

given the right protocol, i agree

the protocol would need to ensure that all clients interested in a
particular collection of emails could be fed the same information

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.

the resources that i think are of interest are emails, meta-data about
emails, collections of emails and meta-data about collections of
emails. these concepts already have natural correspondents in HTTP and
WebDAV

smooth operation means being able to feed information about changes
back to the client which needs a little more thought

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to