On Wed, Mar 19, 2008 at 8:49 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> the recent response is a PITA when using a database backend.
> the
> specification is (as is expected with IMAP) not unequivocal:
>
> <blockquote cite='http://www.faqs.org/rfcs/rfc3501.html'>
> 7.3.2. RECENT Response
>
> Contents: none
>
> The RECENT response reports the number of messages with the
> \Recent flag set. This response occurs as a result of a SELECT or
> EXAMINE command, and if the size of the mailbox changes (e.g., new
> messages).
>
> Note: It is not guaranteed that the message sequence
> numbers of recent messages will be a contiguous range of
> the highest n messages in the mailbox (where n is the
> value reported by the RECENT response). Examples of
> situations in which this is not the case are: multiple
> clients having the same mailbox open (the first session
> to be notified will see it as recent, others will
> probably see it as non-recent), and when the mailbox is
> re-ordered by a non-IMAP agent.
>
> The only reliable way to identify recent messages is to
> look at message flags to see which have the \Recent flag
> set, or to do a SEARCH RECENT.
> </blockquote>
>
> ATM response are cleared when a new count is called for. this means that:
>
> * SEARCH will not usually return recent messages correct since the
> flag will be cleared upon next append or select.
> * RECENT almost always returns just one
>
> probably the best approach would be to clear recent flags not when
> they are first viewed by a session but when a session unselects a
> mailbox. this approach will ensure that SEARCH and RECENT report
> correct values when a single session is logged in.
>
> it may cause some unusual behaviour when more than one session has the
> same mailbox selected: when another session unselects that mailbox,
> all the recent flags for that mailbox will be cleared. so, a client
> may see * 5 RECENT reported but when SEARCH RECENT is called, no
> responses wil be returned.
>
> an alternative would be to remove RECENT from the database and store
> it just in memory
>
> opinions?
Because of my lack of IMAP knowledge, I don't get all the subtilities
of the protocol.
However.
Regarding the RECENT flag the RFC authors seems to say: 'Heck, I don't
know how this should work for myself'.
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. ;-)
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.
HTH,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
