MBOX-Line: From blong at google.com  Mon Nov 26 14:29:38 2012
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] Re: Suspend/Restore feature proposal
In-Reply-To: <20121126152005.Horde.UGsoLB91esWQF9_aGi6UYQ1@bigworm.curecanti.org>
References: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
	<CABa8R6tHP2My0k2LqT1RzHoLQZA+X_jwUMU0cydm2sAwo8f4Fg@mail.gmail.com>
	<20121116143137.Horde.7Kb3aEW5DhM6CnuA2hAx4Q8@bigworm.curecanti.org>
	<e122fa25-9110-4b36-855d-0e7e273c5805@flaska.net>
	<20121121155417.Horde.ZeW7JqTPNxTAI-hTtrAT-Q9@bigworm.curecanti.org>
	<CABa8R6sJfnA=HYk-fmFfpXki91cne_LeqFyuhDebMGeDdsdj7g@mail.gmail.com>
	<20121121183606.Horde.8DDdRoJ261AbQsAiMPfS4w1@bigworm.curecanti.org>
	<CABa8R6u62m0SkAoLa+K8MgQn8CXKxtv5Hnnt6O1muTZQnFqqoA@mail.gmail.com>
	<20121126152005.Horde.UGsoLB91esWQF9_aGi6UYQ1@bigworm.curecanti.org>
Message-ID: <CABa8R6tGF8Uj-MEec6vdHrhkYefhiU0QLGtVXafDwOXb3vnFmQ@mail.gmail.com>

By polling, I assume you mean for calling STATUS?

And my point would be that it wouldn't cost anything on the server.

Imagine, instead of a "special case" resume, that we're instead treating
this as a client that often re-connects.  You'd treat IMAP the same way a
normal "connected" client would, and the server would just keep your
connection in the same connection state, possibly holding any results it
would send you.  You would just "reconnect/resume" and then issue the next
command.  You'd be immediately back in the selected state, but there
wouldn't be any cost associated with it (from the client side) except
perhaps having to update client state if the server gives you updates, but
that just results in faster updates of server state.

You could even mimic Outlook by having a separate "virtual connection" that
handles STATUS calls, and one "virtual connection" for actual folder
actions.

This is essentially trying to turn IMAP into a more HTTP like protocol.

It is more expensive for a server to offer this, though as long as the
client has to "request" a session, it would actually be cheaper for the
server to maintain that state than re-loading it between connections.

Brandon


On Mon, Nov 26, 2012 at 2:20 PM, Michael M Slusarz <slusarz@curecanti.org>wrote:

> Quoting Brandon Long <blong@google.com>:
>
>  On Wed, Nov 21, 2012 at 5:36 PM, Michael M Slusarz <slusarz@curecanti.org
>> >wrote:
>>
>>  Quoting Brandon Long <blong@google.com>:
>>>
>>>  Have you considered not re-establishing a connection every 10s?  This
>>> is a
>>>
>>>> connected protocol, not http.
>>>>
>>>>
>>> From a webmail perspective: if you could tell me how to maintain a
>>> consistent IMAP connection using nothing more than current IMAP commands
>>> and an out-of-the box HTTP server, I would be ecstatic.  That's what
>>> users
>>> demand our software works with, so that's what we need to code for.
>>>
>>> I don't have the UI information in front of me right now, but a user
>>> initiating an action every 10 seconds, at least when managing messages
>>> in a
>>> mailbox (loading a message to read, deleting, copying/moving, reporting
>>> as
>>> spam), seems like a reasonable estimate for discussion purposes.  That's
>>> where I got the 10 second value from.
>>>
>>>
>> And this seems to imply, to me, that you'd be better off with the
>> resume/disconnected session stuff from p-imap/lemonade that I pointed to
>> before.
>>
>> After all, you are likely to need to do at least a select of the same
>> folder for most of those new connections.
>>
>
> This is probably getting too client implementation specific... but in our
> dynamic client a large number of browser requests (XMLHttpRequest) are
> polling requests.  No need to select a mailbox.  So any solution that
> REQUIREs a selection of mailbox on resuming is worthless in a practical
> sense.
>
> michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121126/fa4932be/attachment.html>
