The
simplest way of doing this is to turn the system flags into bit fields and add
a 6 or so bits per message to your per-session in-memory list of messages (you
do have an in-memory list of messages, right?) Then as the user does store and
fetch of the flags, you just flip the bits on and off in the per-session
in-memory list.
From: Pete Maclean [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 19, 2004 1:29 PM
To: Larry Osterman; [EMAIL PROTECTED]
Subject: RE: shared mailbox permanent flags?
Thanks, Larry. I too forgot
about the specialness of \Recent when I wrote that message. My
misunderstanding about the other flags is a different matter though. For
the entire four or so years that I have been working with IMAP up until
yesterday I was confidently convinced that a server was not obliged to handle
system flags that it could not manage as PERMANENTFLAGS. I was quite
distressed to realize my error. Fortunately, in spite of this, my server
does handle such flags correctly (well, I hope correctly -- see below) with the
exception of \Recent. And that I shall fix.
I am now struggling to make sure that I properly understand all the
implications of system-flag handling so that I can confirm that my code is
indeed correct. For a start, a server must list all the system flags
(except \Recent) in a FLAGS response to every successful SELECT or EXAMINE
(even though that seems redundant).
RFC 3510 section 7.1 states that, "If the client attempts to STORE a flag
that is not in the PERMANENTFLAGS list, the server will either ignore the
change or store the state change for the remainder of the current session
only." Now, I suppose that ignoring such a change could be deemed a
reasonable strategy because one could argue that it is effectively equivalent
to storing the change only to have another party immediately do a STORE that
reverses it. However, if a server adopts that strategy, it is equivalent
to its not handling the flag at all (except to the extent that it does not
consider a STORE for the flag to be an error). So it must advertise that
it supports the flag even though it really does not.
Now, what if a server stores the state change for the remainder of the current
session only. Does that mean it stores it *for* the current session
only? I presume so because anything else could be a nightmare. This
suggests that, if the same client creates a second session and selects the same
mailbox, it could see different flag states from the first. Granted,
opening such a second session is probably an ill-advised venture to begin with
(although I have seen it happen) so this inconsistency is hardly a big deal --
never mind that it is something that a properly functioning client should be
prepared for.
By contrast to all this, my reading of the RFC is that, when the \Seen flag is
set implicitly (by virtue of an appropriate FETCH), it must be indeed be set;
there is no option. Now, a server could choose not to set it and hold
forth the same argument as above (that the flag could be instantly reset by a
third party) but that argument breaks down because, if the flag is effective
only for the session involved, then in practice nothing external could sensibly
change it. This all seems a bit of a mess.
What I have said may sound somewhat critical and that may be because I am
rather peeved at my own misunderstanding. My prime intention in writing
this message though is solely to make sure that I now do understand this well.
Pete Maclean
At 12:01 PM 8/19/2004, Larry Osterman wrote:
Ah, you're right - I
forgot about \Recent. \Recent is "special" since it's not a
"real" flag.
From: Pete Maclean [mailto:[EMAIL PROTECTED]]
Sent: Wed 8/18/2004 2:48 PM
To: Larry Osterman; petite_abeille; [EMAIL PROTECTED]
Subject: RE: shared mailbox permanent flags?
I think that either what you say is not quite
correct or I am not
understanding it right. RFC 3501 gives an example of a FLAGS response
that
does not include all the system/built-in flags:
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen
\Draft)
In this case, \Recent is missing. As I read the spec, if you do not
include a particular system flag in this response, it means that you do not
support it for the mailbox. Incidentally, some versions of my server do
not support \Recent at all.
Pete Maclean
At 05:09 PM 8/18/2004, Larry Osterman wrote:
>You MUST support ALL the built-in flags on every mailbox. You might
not
>be able to persist those flag settings, but you MUST support them on a
>per-session basis.
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>On Behalf Of petite_abeille
>Sent: Wednesday, August 18, 2004 2:00 PM
>To: [EMAIL PROTECTED]
>Subject: Re: shared mailbox permanent flags?
>
>Hi Timo,
>
>On Aug 18, 2004, at 22:37, Timo Sirainen wrote:
>
> > FLAGS list shouldn't be empty. It should contain at least the system
> > flags.
>
>Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged
>\Recent and \Seen? Even if they are not applicable for such mailbox?
>
> >> But this doesn't seem to help :/
> >
> > Yep. I doubt there's a way to make it work many (if any) clients.
>
>Sigh :/
>
>PA.