While trying to get QRESYNC working I found a few problems in Tinymail‘s IDLE handling, specifically in its handling of (unsolicited) FETCH responses.
I used to believe some IMAP servers simply ‘forget’ to send certain FETCH responses, but while testing with MBox I noticed that I was receiving all of them correctly. It turned out that I was simply not parsing the FETCH response correctly as the sequence ended up being invalid. Once that was fixed, I found that, would it have been correct, the index was not subtracted with one. IMAP sends sequence numbers starting at one, whereas an array in C obviously starts at zero. If it had worked, it would have marked locally the wrong E-mail as seen or unseen. Ugh.
As a result, the flag changes were not instantly visible. Only notifications about expunges and new messages were really working. This has been fixed of course. This means that you can now start a Tinymail based E-mail client, continue working in another E-mail client, and with the right IMAP server the Tinymail one gets instantly updated about the state changes of messages.
With NOTIFY, the same granularity of change notifications can be achieved for folders. For example, their subscription state, renames, deletions, creations and status changes like the unread and the total counts of each folder. With CONTEXT we can also provide in the future a vfolder that is completely stored at the server. As usual, if you are interested in having this: either fund me or help me implementing it.
An IMAP draft that I really like is CONVERT. Imagine having in a message a document attached in a funny format like Microsoft Word. Do we expect that each and every phone deploys OpenOffice.org just to parse and convert all that data to something that can be viewed? Yeah yeah, the AbiWord guys now want to tell me they have something for phones too, but I can redo the sample with any other existing document format.
Why not putting that AbiWord code in the plugin of an IMAP server in stead? Why consume more bandwidth if perhaps the server can convert it to a smaller format that is immediately suitable for the phone’s display? What about converting large image attachments to the exact size of the display?
Oh, support for QRSYNC is also committed. I will most likely build pre-release 0.0.3 this weekend. I know it has taken me longer than the promised three weeks. The problem was that the amount of bugfixes has decreased drastically. The Modest developers keep telling me that everything is stable and they asked me not to change too much anymore. But now the amount of fixes and even new features is again worthwhile to do a new release.
Hello,
Good to see that you are taking care of implementing QRESYNC.
I guess you are still based on camel evolution code.
Are you planning to reintegrate the changes back to camel evolution ?
Yes and no. For example Matthew Barnes is working on this. His nickname is mbarnes on IRC (#evolution on Gimpnet).
We’re not planning to migrate all changes to Evolution. Although QRESYNC would definitely be possible indeed.