On Thu, 2007-10-18 at 10:46 +0100, Dave Cridland wrote: > On Thu Oct 18 00:41:39 2007, Philip Van Hoof wrote: > > I implemented support for QRESYNC in Tinymail's camel-lite. I never > > tested this because somehow the MBox copy that the friendly guys at > > Isode gave me, is not starting up and I know of no other IMAP server > > that already offers the QRESYNC capability.
> Thanks for the bragging-by-proxy. :-) Well, you guys make an IMAP server that follows the latest IMAP protocol enhancements. Even the proposals that are still in draft like QRESYNC. And some of the people who work on these standards are employed by Isode. It's just fair to mention that. With your help I managed to get my hands on one that does things like QRESYNC, CONDSTORE and ENABLE (which I also had to add, didn't knew about having to ENABLE them too). So I can now start trying to get it actually working too. > I think we're the first to have a released product, but I'm not > certain we're the only ones who've implemented it. Most of the other > closed-source companies have much longer release cycles that we do. > (We made 12 releases this year, and we're not slowing yet). Good > We're certainly not the only ones to have things like CONDSTORE, > which is much harder work, and gets both client and server 90% of the > way there, so QRESYNC will probably start to appear soon. Awesome! And let's convince the latecomers to hurry up with it. It does make quite a lot of things more easy. Especially the VANISHED response is very useful indeed. No more fiddling with sequence numbers and single line EXPUNGE responses, and all immediately in the SELECT's response packed together with the flag updates. > > I'll retry tomorrow after actually reading the documentation that > > came > > with it. > Reading the docs? You're weird... I wish certain IMAP developers, who's name(s) shall not be pronounced, would read the specs too :-\. That would make the lives of client developers far less frustrating. > > I'm for example not sure about the VANISHED reply (and the exact > > meaning > > of that "earlier" parameter). > > > > > EARLIER indicates that the VANISHED response you're looking at > doesn't refer to an event that's just occured, but to one (or lots) > that occured at some unspecified point in time, probably when you > weren't looking. > To put it another way, these EARLIER ones are resynchronization data, > and not event notifications. Aha okay (so .. I can just remove the items with that UID) :) > > ps. I added the nice folks at Evolution in CC, as some of these code > > warriors are planning to migrate some of newer features in > > camel-lite to > > upstream camel. > > Hoorah - I know several people within Isode using Evolution who'll be > happy at that. Feel free to bug me if there's anything I can do to > help (test accounts, etc). Will do. Although the porting of all this to Evolution will not be for tomorrow I think. Well, CONDSTORE and QRESYNC are more easy for them to backport to upstream Camel. IDLE is a bit more difficult as this involves dealing with the events in their ui pieces too (and the patch for IDLE is a little bit ugly as I had to do certain things that are not possible with how the stream-related code is structured in upstream Camel). -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog _______________________________________________ Evolution-hackers mailing list Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers