95 lines
4.0 KiB
Plaintext
95 lines
4.0 KiB
Plaintext
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>
|