On Fri, Mar 21, 2008 at 8:10 AM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
<snip> > Because of my lack of IMAP knowledge, I don't get all the subtilities > of the protocol. IMO subtilities->stupidities ;-) > However. > > Regarding the RECENT flag the RFC authors seems to say: 'Heck, I don't > know how this should work for myself'. the IMAP RFC is naff and suffers from design by committee > This is the definition of the flag: > > \Recent > Message is "recently" arrived in this mailbox. This session > is the first session to have been notified about this > message; if the session is read-write, subsequent sessions > will not see \Recent set for this message. This flag can not > be altered by the client. > > If it is not possible to determine whether or not this > session is the first session to be notified about a message, > then that message SHOULD be considered recent. > > If multiple connections have the same mailbox selected > simultaneously, it is undefined which of these connections > will see newly-arrived messages with \Recent set and which > will see it without \Recent set. > > In the first sentence, the flag is defined recursively. Brilliant. > In the second sentence, the state of a mail (said flag) is defined by > the first sessions accessing the mailbox. Mmh. > And after that, it literally says: Except if you can't figure it out, > then do what you want. ;-) how very IMAP :-) which is why i spent the energy to create a means of playing commands at dovecot and recording the results into a functional test script > So my very naiv opinion would be to clear the flag early (after the > first session sees it, but before mailbox unselect). > Inconsistencies seem to be taken into account. that's the current approach however, this breaks SEARCH and APPEND when a message is APPENDed, the number of RECENT messages reported should be at least one more than the last report. when a session APPENDs a message then this needs to be RECENT for the appending session. however, when a protocol other than IMAP adds a message to the database then it probably needs to be marked recent. the mailbox has no way of telling whether a request to add a new mail comes from IMAP or some other protocol. a client must be able to SEARCH for messages flagged RECENT. clearing the flag means that SEARCH cannot find them. basically, RECENT is a complete PITA is ignored by most IMAP clients since it's not reliably specified. IMAP clients typically maintain local caches and just check their caches: anything they don't have is recent as far as they are concerned. IMO this is much more reasonable then the RECENT flag. however, since this is JAMES, i'm aiming for a complete implementation of the specification. which means finding a way to make RECENT work :-/ due to it's poor definition, RECENT makes no sense for anything other than IMAP. in principle, exposing protocol-specific rubbish through the mailbox API is bad. the IMAP session might reasonably maintain a list of RECENT mail but SEARCH requires RECENT and is implemented in the mailbox layer to allow optimisation. so SearchQuery would need to allow a list of RECENT mail to be passed in. that's not unreasonable. the session would query for a list of RECENT mail when a mailbox is SELECTed, clearing RECENT from any it finds. the session would maintain a list of UIDs. when APPENDing it would unset the RECENT flag for the APPENDed mail and then just add the UID to the list of RECENT mail. non-IMAP sessions (and COPY actions) would need to set the RECENT flag. can anyone think of a more elegant solution? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
