Subject: [lemonade] NOTIFY simplification

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Nov 2007 12:11:54 +0100

Hi,

since every Notify implementer was in the same room as I last week I 
asked: what can and should we simplify here?.

1. The mailbox* events. We decided to merge this. It seemed unlikely to 
us that a mailbox would want to know about some but not all of 
mailboxcreated, mailboxrenamed and mailboxdeleted. If you disagree, 
speak now or hold your peace. (And if you speak, mention some use 
cases.)

2. The search expression for message events. Server implementers wanted 
to drop it. Client implementers said "but it might be useful". Two use 
cases were presented: "I want to be notified of mail from my boss, but 
not from anyone else since push is expensive" and "I want to be 
notified of incoming mail, but I get a lot of mailing-list mail which I 
don't want to read on my mobile client".

I personally find the first use case extremely weak. It's trotted out 
all the time, but I've never seen anyone do it (it could be done using 
sieve and fileinto+keep). Some people let their esteemed manager pay 
the phone bill and do not economise on usage, others pay it themselves 
and treat their boss like everyone else.

The second is much better. IMO it's not strong enough to justify keeping 
the search program since most people who get much mailing-list mail 
divert it into separate mailboxes, but opinions may vary on that.

Opinions?

3. The fetch program for the selected mailbox. Peter wanted it out, 
various other people wanted it in, myself included. As I interpreted 
it, we have rough consensus for keeping it in.

4. Other ideas for simplification?

Arnt

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Nov 2007 15:03:33 +0000

I'll answer all these points, since noisy consensus is better than  
silence.

On Mon Nov 26 11:11:54 2007, Arnt Gulbrandsen wrote:
> 1. The mailbox* events. We decided to merge this. It seemed  
> unlikely to us that a mailbox would want to know about some but not  
> all of mailboxcreated, mailboxrenamed and mailboxdeleted. If you  
> disagree, speak now or hold your peace. (And if you speak, mention  
> some use cases.)
> 
> 
I'm very much in favour of this. Any way to keep the costs down.

> 2. The search expression for message events. Server implementers  
> wanted to drop it. Client implementers said "but it might be  
> useful". Two use cases were presented: "I want to be notified of  
> mail from my boss, but not from anyone else since push is  
> expensive" and "I want to be notified of incoming mail, but I get a  
> lot of mailing-list mail which I don't want to read on my mobile  
> client".
> 
> I personally find the first use case extremely weak. It's trotted  
> out all the time, but I've never seen anyone do it (it could be  
> done using sieve and fileinto+keep). Some people let their esteemed  
> manager pay the phone bill and do not economise on usage, others  
> pay it themselves and treat their boss like everyone else.
> 
> The second is much better. IMO it's not strong enough to justify  
> keeping the search program since most people who get much  
> mailing-list mail divert it into separate mailboxes, but opinions  
> may vary on that.
> 
> Opinions?
> 
> 
Basically, my impression was that client implementors essentially  
want a degree of inbound filtering, but for the selected mailbox,  
filtering the output of "the fetch program" makes more sense than  
filtering "the notifications".

More interesting is the related problem Philip Van Hoof outlined,  
whereby we want to be able to remove spurious SELECT/synch cycles by  
ensuring that NOTIFY is emitting only relevant data for non-SELECTed  
mailboxes, by allowing the client to specify what counts as "unread".

> various other people wanted it in, myself included. As I  
> interpreted it, we have rough consensus for keeping it in.
> 
> 
Peter wants this moved to CONTEXT. My gut feeling is that this is  
wrong, but Peter's arguments are persuasive - namely, that if you're  
going to the effort of maintaining an active filter, then keeping all  
filtering in the same place is easier to implement.

My opinion is yoyoing on this at the moment. I appreciate that my  
primary argument against this is a gut feeling combined with an  
æsthetic argument.

One thing that nags at me is that the complexity shifts from managing  
multiple SEARCH programs to managing multiple FETCH programs, and I'm  
not sure that's a trade-off that's universally going to be a simple  
thing to handle.

Moreover, I suspect - possibly incorrectly - that in many cases, a  
single CONTEXT for viewing will be used, so it may make no difference  
at all.

I think I need to implement all this to get a better understanding of  
how it can be used, and how it might fit together at either end.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Nov 2007 16:34:30 +0100

>  filtering in the same place is easier to implement.

Putting it in context would double it for me, since I already run a 
fetch program in the session: A mailbox change triggers a fetch of some 
combination of uid, flags, annotations and modseq, with changedsince to 
select the right messages. I'd hate to have both session and search run 
that kind of thing.

Arnt