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
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
