On Fri, Mar 21, 2008 at 5:03 AM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > 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.
That makes sense to me. I would implement it the way you think logically an IMAP client is implementing this, i.e., tracking it's own list of received messages and then seeing others as RECENT. Then as you say, when you search for the flag, the client has to send its list of UIDs of what it considers RECENT since there is no actual flag on the message itself. IOW, RECENT sounds like a failed attempt to describe a rather commonplace and well understood notion, and I would go defer to the notion (how you would expect this to behave) and suffer the performance penalty that is inherent with that notion rather than try to complicate or reinvent the notion. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
