Re: [Imap-protocol] Re: Suspend/Restore feature proposal

On Mon, Nov 26, 2012 at 2:57 PM, Michael M Slusarz <[email protected]>wrote:

> Quoting Brandon Long <[email protected]>:
>
>  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

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol