You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Andrew C. Oliver" <ac...@buni.org> on 2007/01/28 18:19:34 UTC
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation
was: Jsieve Configuration]
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:robertburrelldonkin@gmail.com]
>> 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 <sk...@gmail.com> wrote:
>>
>>> On 1/24/07, robert burrell donkin <ro...@gmail.com>
>>>
>> wrote:
>>
>>>> On 1/23/07, Serge Knystautas <sk...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>> !EXCUBATOR:1,45bb396239413124693792!
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation
was: Jsieve Configuration]
Posted by "Andrew C. Oliver" <ac...@buni.org>.
>
> smooth operation means being able to feed information about changes
> back to the client which needs a little more thought
>
With HTTP 1.1 persistent connections this is possible and still allows
some of that pool magic. It can be a configurational pain (timeouts on
routers and stuff) but possible. A conditional get type setup should
always be a fallback. A capabilities advertisement should say if PUSH
is available. If not then fall back to PULL w/conditional get which
*MUST* be supported.
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation was: Jsieve Configuration]
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, Andrew C. Oliver <ac...@buni.org> wrote:
> You know who is doing this really successfully and even made it a key
> upselling point?
> I imagine there are even performance numbers for it. I know I'm
> speaking heresy...
yeh (but i'm trying to learn as little as possible about it). i
suspect that sooner or later they'll start showing up on the DAV lists
(if this idea ever gets off the ground). then we might all learn more.
it should be considerably easier to make a more reasonable but more
verbose protocol run at adequately speeds than IMAP
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation
was: Jsieve Configuration]
Posted by "Andrew C. Oliver" <ac...@buni.org>.
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
>
> had a talk with some of the DAV folks last year. AIUI the right way to
> do it would be to standardize a small amount of email specific stuff
> on top of DAV (rather than force everything to work within DAV).
>
> a lot could be achieve by using DAV properties to access email
> specific meta-data (for example unread counts)
>
> but yes, xml is the preferred DAV format. it's not as terse as
> standard email formats and would require parsing. so yes, the
> question would be how big an impact this would be.
>
> i'm interested in associating and sharing meta-data with email so i'm
> willing to trade a little verbosity for being able to create servers
> and clients more easily.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation was: Jsieve Configuration]
Posted by robert burrell donkin <ro...@gmail.com>.
On 1/31/07, Andrew C. Oliver <ac...@buni.org> wrote:
>
> >
> > 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
> >
> U/F it looks like although WEBDAV would be natural, just getting a list
> O'stuff in a folder is not very terse...I wonder how bad this would be...
had a talk with some of the DAV folks last year. AIUI the right way to
do it would be to standardize a small amount of email specific stuff
on top of DAV (rather than force everything to work within DAV).
a lot could be achieve by using DAV properties to access email
specific meta-data (for example unread counts)
but yes, xml is the preferred DAV format. it's not as terse as
standard email formats and would require parsing. so yes, the
question would be how big an impact this would be.
i'm interested in associating and sharing meta-data with email so i'm
willing to trade a little verbosity for being able to create servers
and clients more easily.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation
was: Jsieve Configuration]
Posted by "Andrew C. Oliver" <ac...@buni.org>.
>
> 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
>
U/F it looks like although WEBDAV would be natural, just getting a list
O'stuff in a folder is not very terse...I wonder how bad this would be...
> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: RESTful email [WAS Re: MailboxManager API and session orientation was: Jsieve Configuration]
Posted by robert burrell donkin <ro...@gmail.com>.
On 1/28/07, Andrew C. Oliver <ac...@buni.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org