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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

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

>> From what you are telling me though, I should be using  
>> STATUS_UIDNEXT_FORCE for this since the data might not be available  
>> without the extra server call, correct?
>
> Yes - this is a MUST, not a SHOULD.  Or else on certain servers, you  
> will never see UIDNEXT change - it will always be 0.

Done, thanks for the advice.

> From what it sounds like, you are keeping duplicate cache data  
> around.  We only need one cache on the server - let the IMP Imap  
> object do that for you.  Then you just need to carry around the  
> state of your mailbox as it is known on the activesync device.  This  
> can already be easily done, without IMAP extension querying, via  
> getCacheId().

When QRESYNC is in use, that's pretty much what I'm doing. I persist  
the state of the mailbox using MODSEQ, UIDVALIDITY, and UIDNEXT. It's  
when QRESYNC isn't available that I'm also storing the UIDs and flags.


> What is missing right now is the ability to take this cache ID token  
> and give it to Horde_Imap_Client_Base, and have it do all the  
> necessary things to 1) check the UIDVALIDITY, 2) return the list of  
> flag changes, and 3) return the list of vanished UIDs.  This is what  
> I am going to write.  It would do things like automatically use  
> STATUS_SYNC* if the cache token matched the IMP Imap object cached  
> state when opening the mailbox for the first time in that page load.  
>  It would also be able to handle CONDSTORE-only servers, and be able  
> to do syncing on basic IMAP4rev1 servers.  And this is all  
> transparent to the calling code.
>
> Although I mentioned that getCacheId() already exists, it will not  
> be used for the new code - it has the design flaw of trying to allow  
> data access to the string itself (the API documentation for the  
> return value explains, for example, how to grab the uidvalidity).   
> Instead, I am going to implement a getSyncId() method that returns a  
> string that has no defined format (it's probably going to be nothing  
> more than a base64 encoded version of the getCacheId() result).  And  
> then I will implement a syncMailbox() method that takes the token as  
> its only argument.  This method will throw an exception if the  
> UIDVALIDITY changed, will return false/null if the mailbox hasn't  
> changed, and will return four entries if the mailbox has changed:
>
>   - flags: Horde_Imap_Client_Ids object of the list of messages  
> whose flags changed.
>   - newmsgs: (Boolean) Whether new messages were delivered to the mailbox
>   - syncid: (String) The new syncid token.
>   - vanished: Horde_Imap_Client_Ids object of the list of messages  
> that were expunged.
>
> Would this be sufficient for what you need to do in your code?

This sounds great, but I'm still a little fuzzy on how this would work  
for ActiveSync without ActiveSync controlling the caching.  For  
example, when not using QRESYNC how would flag changes be determined  
between any arbitrary state on the ActiveSync client and the current  
server state? I need to track more than one different state in case  
the client reissues the last request. Would the caching be able to  
still calculate the deltas for an older syncId?  With QRESYNC I know  
this would be possible, and is basically what I'm already doing... but  
if I give up my own caching of the UIDs when not using QRESYNC, how  
will I be able to still get at this data?

Currently, the mailbox state is saved to the database, keyed by  
ActiveSync's syncKey. When not using QRESYNC, each entry is a complete  
snapshot of the ActiveSync folder state - a list of UIDs on the device  
along with any flags. There is normally two different versions of this  
data - the state as it should be if all changes that were just sent  
were received successfully, and the state of the device *before* the  
changes were sent.

If what you are talking about would be able to handle this  
transparently, then that would be a complete solution for me,  
otherwise I will still probably need to track UIDs and flags  
independently if not using QRESYNC.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20121105/4929726f/attachment.bin>