Subject: [lemonade] RE: notify

From: Peter Coates <[email-masked]>
Date: Fri, 14 Dec 2007 09:20:57 -0800

First , the principle of operation of our server is that there are
potentially several variant views of a mailbox, one for each context that
has it open.  They synchronize with each command (up to a point...)

So postulate that context 1 asks for newmessages only:

C1: 1A NOTIFY (SELECTED ewmessages)
S:  ...
S:  1A OK

Then context 2 deleted and expunges a message

C2: 2A STORE 2 +flags \deleted
C2: 2B EXPUNGE
S:  ...
S:  * EXPUNGED 2
S:  2B OK

Session 1 receives notification of the expunge, but ignores it until the
next normal imap moment

A new message is delivered.  Session1 is informed of this, and wants to
present information to the user.  But the "real" version of the mailbox has
a message expunged as well as a new message.  It CAN NOT report the new
message without also reporting the expunged message.

Peter

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: December 14, 2007 05:07
To: Peter Coates
Subject: Re: notify

Peter Coates writes:
> Arnt,
>
> I'm looking at implementing this, now that I've simplified it!
>
> And I have run into a problem. If something has happened to the 
> mailbox outside of my context, I have two versions of what is in the 
> mailbox: the one in my context, and the true one. I can ignore a 
> notification that a message has been expunged, if the user has not 
> asked for such notifications. But that change is in the "true" 
> version of the maibox. If after an expunge I get notification of new 
> mail, then I have two choices: either not report the new mail, or 
> report both the new mail and the expunge. I think I have to do the 
> first option, not report the new mail.

Somehow this paragraph doesn't make sense to me. At all. Maybe I'm 
dense, but could you try again?

> This requesting not to be told about expunges is a real pain. What 
> does it actually mean? It means do not report them except when you 
> would be told about them anyway.

It means to not report them unsolicited.

> I would to expand the words at the end of section 5 about this. It 
> currently reads:
> ...
> I would like to add to this:
>
> If a client specifies some but not all of MessageNew, MessageExpunge, 
> FlagChange, and AnnotationChange for the SELECTED mailbox, the server 
> MAY omit some of the requested notifications. Clients SHOULD specify 
> all or none of these event types.

I don't like this... for example it makes sense to want new mail, but 
not care about flags. That's what my hobby client does, and in this 
respect I believe it behaves like a good lemonadish client should. 
(It's odd in various other ways, so I wouldn't argue that everything it 
does is worth consideration.)

1. It wants to be notified of mail immediately, even if no command is in 
progress, and wants the UID, From and Message-ID at once. I believe 
this is reasonable.

2. It doesn't want flag updates. Flag processing can be done on the 
server instead of fetching flags. For example, instead of showing 
unread messages by issuing "uid fetch 1:* flags" and categorising on 
the client, it asks the server to "uid search unseen", and when a new 
message or HIGHESTMODSEQ arrives, it updates the result with something 
like "uid search unseen changedsince x". Like CONTEXT, except 
implemented on the client.

Maybe few clients will be like this, but it makes sense, and IMO it's 
not odd or perverted. Rather, it's how a good lemonadish client can 
behave, so it shows that one can reasonably want "some but not all of 
these event types".

> I do not need AnnotationChange to be listed here, but someone might.
>
> I believe I also missed that it makes no sense to specify any event 
> types other than these four for SELECTED.

I agree.

Arnt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 18 Dec 2007 16:27:18 +0100

Peter Coates writes:
> potentially several variant views of a mailbox, one for each context 
> that has it open. They synchronize with each command (up to a 
> point...)
>
> present information to the user. But the "real" version of the 
> mailbox has a message expunged as well as a new message. It CAN NOT 
> report the new message without also reporting the expunged message.

Why not?

I do basically the same thing and don't have this problem. If the 
expunge cannot be sent, it just isn't. When it can be sent, it is. Each 
time I look at what I can send, the code does something like this:

    if the set of unreported expunged messages is nonempty
       if expunges can and should be sent now
          send the expunges, adjust the MSN-UID map, clear the set
   if the set of messages with unreported flag updates is nonempty
      if flag updates can and should be sent now
          send the updates, clear the set
    if the set of new messages is nonempty
       ... you get the idea

Perhaps I'm misunderstanding you, or perhaps there is some subtle point 
that divides our two implementations.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Dec 2007 08:45:07 -0800 (PST)

On Tue, 18 Dec 2007, Arnt Gulbrandsen wrote:
> I do basically the same thing and don't have this problem. If the expunge 
> cannot be sent, it just isn't. When it can be sent, it is.

I don't have this problem either.  Expunge announcement is separate from 
new mail announcement.

In my mail stores, expunge message space is only recovered at an 
exclusive-access point.  So shared expunge just makes the message become 
invisible in the sessions which have reported the expunge (or new 
sessions), at which point it is easy to implement the ideal IMAP semantics 
for expunge.  Later space reclamation is a cleanup operation.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Peter Coates <[email-masked]>
Date: Tue, 18 Dec 2007 10:29:52 -0800

The problem is the "index file", which holds some information about each
message.  This is a contiguous array of records.  If a message is deleted,
the file is rewritten from that point on.  When a context resynchronises, it
rereads this file and that becomes its index into the mailbox.  If I fail to
report a deleted message, my index is wrong.  Changing this would be close
to a rewrite.

Peter

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: December 18, 2007 07:27
To: [email-masked]
Cc: Peter Coates
Subject: Re: notify

Why not?

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Dec 2007 10:59:51 -0800 (Pacific Standard Time)

> report a deleted message, my index is wrong.  Changing this would be close

I have a similar implementation, but I do not require that a message exist 
in the index, nor do I remove messages that are not in the index until I 
am at a point where it is safe to expunge.  I don't have to worry about 
index rewrites putting an expunged message back since I would never 
rewrite the index unless I am at a safe to expunge point.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.