Re: [Dbmail-dev] Uidvalidity not changing
Geo Carncross wrote: Now, I recommend that servers make FETCH+ENVELOPE fast, and client implementers should use: x FETCH 1:* ENVELOPE *Very* cheap in dbmail atm. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] Uidvalidity not changing
On Thu, 2006-09-14 at 10:19 +0200, Lars Kneschke wrote: Aaron Stone [EMAIL PROTECTED] schrieb: Ok. I changed my code. But should not change that value at least on delete? Nope, I don't think so. When UIDVALIDITY changes, it means all UID's that you have cached must be thrown away and you have to find out what the new UID's are for the messages in the mailbox. Unfortunaly it does not seem to be documented really good in the RFC. But it is also not important for me, as i now query the number of messages and nextuid. That solves the problem for me. RFC 2060 is gibberish. UIDVALIDITY is needed because UIDs must be strictly increasing. The right way to get UIDs should have been x FETCH 1:* UID and let UIDs be binary string, but it's much too late now. Now, I recommend that servers make FETCH+ENVELOPE fast, and client implementers should use: x FETCH 1:* ENVELOPE Use a hash of the envelope response as the unique identifier. I'd recommend servers give out the capability FETCH-IS-FAST for interactive IMAP clients. Implementing RFC 2060 in this way makes it much easier to synchronize email knowledge, and would greatly simplify distributed IMAP services... There's an interesting extension, too: RFC 4315, UIDPLUS. I don't think it's implemented in DBMail (?). Not when having a look at the capabilities. Nobody has a meaningful implementation of UIDPLUS. Furthermore UIDPLUS is extremely complicated. Furthermore, FETCH+ENVELOPE is already supported. I don't think non-interactive IMAP clients should ever bother with UID/UIDVALIDITY. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
[Dbmail-dev] Uidvalidity not changing
Hello! I started caching sort results, until uidvalidity changes. But uidvalidity does not change when i receive a new mail or delete a old one. I have tested this with a 2 weeks old version. Tomorrow i'll test it with latest SVN.
Re: [Dbmail-dev] Uidvalidity not changing
Aaron Stone [EMAIL PROTECTED] schrieb: UIDVALIDITY is constant on a per-mailbox basis so long as the UIDs of each message still point to the same messages. To look for new messages, you need to check the current message sequence number. EXAMINE, SELECT and STATUS can get it for you. In fact, we should time them to see if they run at significantly different speeds. Ok. I changed my code. But should not change that value at least on delete?
Re: [Dbmail-dev] Uidvalidity not changing
On Wed, Sep 13, 2006, Lars Kneschke [EMAIL PROTECTED] said: Aaron Stone [EMAIL PROTECTED] schrieb: UIDVALIDITY is constant on a per-mailbox basis so long as the UIDs of each message still point to the same messages. To look for new messages, you need to check the current message sequence number. EXAMINE, SELECT and STATUS can get it for you. In fact, we should time them to see if they run at significantly different speeds. Ok. I changed my code. But should not change that value at least on delete? Nope, I don't think so. When UIDVALIDITY changes, it means all UID's that you have cached must be thrown away and you have to find out what the new UID's are for the messages in the mailbox. There's an interesting extension, too: RFC 4315, UIDPLUS. I don't think it's implemented in DBMail (?). Aaron
Re: [Dbmail-dev] Uidvalidity not changing
Aaron Stone [EMAIL PROTECTED] schrieb: Ok. I changed my code. But should not change that value at least on delete? Nope, I don't think so. When UIDVALIDITY changes, it means all UID's that you have cached must be thrown away and you have to find out what the new UID's are for the messages in the mailbox. Unfortunaly it does not seem to be documented really good in the RFC. But it is also not important for me, as i now query the number of messages and nextuid. That solves the problem for me. There's an interesting extension, too: RFC 4315, UIDPLUS. I don't think it's implemented in DBMail (?). Not when having a look at the capabilities.
