You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/03/19 20:49:20 UTC
[IMAP] RECENT flag :-/
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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] RECENT flag :-/
Posted by Serge Knystautas <sk...@gmail.com>.
On Fri, Mar 21, 2008 at 5:03 AM, Robert Burrell Donkin
<ro...@gmail.com> 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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] RECENT flag :-/
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Mar 21, 2008 at 8:10 AM, Bernd Fondermann
<be...@googlemail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] RECENT flag :-/
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 19, 2008 at 8:49 PM, Robert Burrell Donkin
<ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org