102 lines
5.0 KiB
Plaintext
102 lines
5.0 KiB
Plaintext
MBOX-Line: From blong at google.com Mon Nov 26 15:30:00 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: <20121126155721.Horde.a3j2EWFDFOo-xkaflrURBQ2@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>
|
|
<CABa8R6tGF8Uj-MEec6vdHrhkYefhiU0QLGtVXafDwOXb3vnFmQ@mail.gmail.com>
|
|
<20121126155721.Horde.a3j2EWFDFOo-xkaflrURBQ2@bigworm.curecanti.org>
|
|
Message-ID: <CABa8R6tOshnrGPGCdb0QToAx8xjWVWY+RBu0Uw8cZ2NH3=TvZw@mail.gmail.com>
|
|
|
|
On Mon, Nov 26, 2012 at 2:57 PM, Michael M Slusarz <slusarz@curecanti.org>wrote:
|
|
|
|
> Quoting Brandon Long <blong@google.com>:
|
|
>
|
|
> By polling, I assume you mean for calling STATUS?
|
|
>>
|
|
>
|
|
> Well hopefully LIST-STATUS exists on the server, because that makes a huge
|
|
> performance difference. (For some reason, a larger number of users will
|
|
> whine and complain incessantly unless the ability to poll all mailboxes is
|
|
> enabled. Why anybody wants to poll mailboxes other than those in which
|
|
> messages are being delivered are beyond me. But this is a feature that
|
|
> users demand, so we have to support it unfortunately.)
|
|
|
|
|
|
sure.
|
|
|
|
|
|
> 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.
|
|
>>
|
|
>
|
|
> This would be great. But implementation of this would be orders of
|
|
> magnitude more difficult than the more simple SUSPEND case and, at least in
|
|
> part, would be duplicating behavior of QRESYNC.
|
|
|
|
|
|
More difficult then you SUSPEND, sure. Easier than QRESYNC. I don't
|
|
really see the duplication, however.
|
|
|
|
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.
|
|
>>
|
|
>
|
|
> What I get out of this is that you think QRESYNC was the result of an
|
|
> incorrect design decision and, instead, the proposal you previously linked
|
|
> to in this thread should have won out.
|
|
|
|
|
|
I wasn't on the list at that time, so I have no idea what the debate looked
|
|
like. I view them as different, however. QRESYNC requires little extra
|
|
storage and can be persisted for any length of time. I find it odd that it
|
|
mentions "mobile, frequently disconnected" as its still a fairly extensive
|
|
negotiation between client and server. Its certainly a win for any client
|
|
when re-connecting, regardless of how long ago that was, and fills a hole
|
|
in the CONDSTORE case. So no, I don't think QRESYNC is an incorrect design
|
|
decision. Its possible a "not imap" protocol could conceive of a better
|
|
way, in syntax or otherwise, of passing the needed information to re-sync
|
|
the client and server, but QRESYNC has to fit the task given it.
|
|
|
|
Also, for the mobile case, its probably more of a case of "uncontrolled"
|
|
connection closing, which isn't as useful a case, because you don't know
|
|
which commands "finished" executing on the server and which didn't make it.
|
|
|
|
I view the advanced suspend/resume as more of a "client always
|
|
disconnects". Mobile clients might be able to use it by frequently
|
|
disconnecting, depending on the exact nature of the disruptions that occur,
|
|
I'm not a mobile expert to know.
|
|
|
|
I'd view this as more useful in the "likely to re-connect in ~1 minute"
|
|
case, the server probably wouldn't hold onto the data longer. It would be
|
|
implemented by separating the connection data out of the connection so that
|
|
it can be kept longer than the connection and re-connected to, and then a
|
|
task to remove old ones after some timeout.
|
|
|
|
I can't speak to which one would be more likely to be adopted, both seem
|
|
rather specific to a certain use case. For instance, your entire use case
|
|
would be avoided if you had a persistent server to maintain your
|
|
connections for you, instead of being a CGI.
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121126/25840739/attachment.html>
|