On Tue, 01 Oct 2002 14:48:16 -0700
Chris Newman <[EMAIL PROTECTED]> wrote:
> Does this imply that concurrent sessions see flag change notifications in
> response to the next command they issue (as Outlook assumes)? Or are lazy
> notifications permissible (where concurrent sessions may get delayed
> notification of flag changes)?
>
> That does have scalability and design implications for the server in
> addition to determining what the client can assume.
While our servers deliver notifications to all sessions at the same time
WITHIN the server, it does not mean that ANY client (including the client
that has just performed the STORE command) can get it immediately. It may be
simply impossible - for example, there is some other operation pending or
sending huge response data (for a different command) via that session
channel at that time, or, finally, the server can be sending other message
status updates to that client/session at this time, or the server can be
sending some [ALERT]'s, for example.
So the terms "immediate" and "lazy" can hardly be applied even to the same
session. A client can never assume that it gets "all" mailbox updates
"immediately". The same applies to the EXISTS response - a message can be
added to the mailbox at any time, but the client may get a notification long
after that moment - for whatever reason.
What the server MUST ensure is the consistency of the client view. If the
client has not received the N EXISTS response, the number of messages in the
client "view" should be N-1. If the client has not received the EXPUNGE
response, the number of messages in the client "view" should remain the
same, with attempts to fetch already deleted messages returning NO/(NIL NIL
NIL).
A more important issue is the STORE [+-]FLAGS commands in a multi-session
envir.
It's always a bad practice to use the STORE FLAGS command, so let's look at
the STORE +FLAGS commands, for example, if client wants to add the \ANSWERED
flag at the moment when some other client has added the \FLagged flag to the
same message. If the client uses the STORE FLAGS (\Seen \Answered) command,
that's too bad, and will never work reliably. But let's assume the client is
smart and it is sending the STORE +FLAGS (\Answered) command.
If the client has not received the status update saying that the \FLagged
flag has been added, nothing bad would happen, eventually it will get the
(\Seen \Answered \Flagged) response.
But if the SERVER side of the session has not received this info yet (i.e.
it's not aware that the \Flagged flag has been added), then it CAN be a
problem - depending on how the message store is designed. If the message
store itself does not support the +FLAGS -FLAGS operations, and only can
work with the FLAGS (i.e. the message store has only one method:
mailbox->setNewFlags(messageID,{newflags}) then such a server is in
trouble.
Bottom line: there is no real difference between "immediate" and "lazy" type
of operations. The servers should do their best to deliver updates as soon
as possible, but they can never deliver them "immediately".
The real problem is the semantics of the "+FLAGS" and "-FLAGS" operations on
the server side: if the message store does not support atomic +-FLAGS
operations, then the *server* sides of all sessions accessing the same
mailbox MUST be notified immediately about all status updates.
> - Chris
Sincerely,
Vladimir
