[dev] STATUS_SYNC* discussion (Was: [Tickets #11612] Re: Broken imap fetch query)

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
> <snip>
>
>> Why are you storing/comparing flags?  I don't think it's asking too  
>> much to require someone who wants to use activesync to be using a  
>> CONDSTORE server, or else they are not getting flag changes.   
>> That's the way IMP used to work, and is a reasonable trade-off.
>
> Honestly, because I want to avoid the "It works with ZPush"  
> complaints and it isn't that much more work to implement. Few things  
> will irritate users more than seeing an inbox full of unread  
> messages on their device after they have already read them on the  
> desktop. I already need to get the flag state from the server anyway  
> (I have to filter out the /deleted flag since AS doesn't support  
> it). Do you have any information regarding the prevalence of  
> CONDSTORE support in modern IMAP servers? If it's mostly ubiquitous  
> then I'd have no problem removing it.

I wouldn't say it is ubiquitous.

Instead, I classify ActiveSync as an "advanced" feature.  In its  
current state, I don't believe it necessarily should work out-of-the  
box with whatever IMAP server you throw at it.  (My opinion:) if I was  
coding it, I would force usage of a CONDSTORE-enabled server for flag  
caching.  If someone really wants to use ActiveSync, and do it right,  
this is a more than reasonable request.  It's sort of like dynamic  
mode - yes, it would be great to tweak it so it could work with older  
browsers, but at a certain point it makes more sense to say "Hey! You!  
You want to use this advanced interface?  You need to do yourself a  
favor and install a modern browser!".  Same thing with ActiveSync - my  
belief is that it is a more than valid expectation that someone has to  
be running a somewhat recent IMAP server to be able to use it.  And  
there are freely available IMAP servers that should be used anyway for  
other performance improvements they bring (Cyrus; Dovecot).

Again, this is all my opinion.

>> I look at this as analogous to "mailbox" support in POP3.  It would  
>> definitely be possible to create a system on the Horde/IMP server  
>> that would allow mailboxes to be abstracted on top of the POP3  
>> model (i.e. you keep a local message-id map using SQL storage to  
>> indicate which messages live in which mailboxes).  But that's  
>> really a waste of time and re-inventing the wheel since this  
>> problem has already been solved by IMAP.  Same with flag change  
>> tracking.  This issue has been solved by CONDSTORE.  Re-inventing a  
>> wheel as a way to work around this isn't useful when you can just  
>> tell an admin to upgrade their IMAP server.
>>
>> And you should be storing UIDs regardless of whether QRESYNC is  
>> available.  It can drastically reduce the amount of work necessary  
>> to resync as seen by the recent VANISHED discussion on the dovecot  
>> list. At a minimum, keep track of the lowest/highest known UIDs so  
>> that you can provide a range string to the IMAP commands rather  
>> than doing an all message command ('1:*').
>
> Yeah, I've already come to the conclusion that I need to stop  
> relying on QRSYNC for determining EXPUNGED messages. I'll be adding  
> this shortly.

This goes to more than working around the VANISHED behavior.  For  
example, determining the exact list of cached messages now allows you  
to use the vanished() command to determine the deleted list, even if  
the server doesn't support QRESYNC.

>> All FETCH data should be cached by the IMP Imap Client cache  
>> object.  You should not be caching any FETCH details in activesync  
>> code.
>
> I don't *think* I'm caching this anywhere now...

If you are storing flag data, you are caching FETCH details.  But you  
have said that this was a design decision, so now that I have beat  
into you the pros/cons of that decision, my job here is done.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]