Re: [lemonade] WGLC NOTIFY

On Wed, 2008-06-04 at 09:51 +0100, Alexey Melnikov wrote:
> > Anyway I think this is too restrictive if using NOTIFY basically 
> > requires the client to drop using MSNs.
> 
> After rereading some portions of draft-ietf-lemonade-imap-notify, I 
> would like to correct this: a client using NOTIFY can't use MSNs in 
> commands it is issuing. However it will still be using MSNs to process 
> server responses.

I'd hate to see that happen. It took me a while to understand that MSNs
can be useful and I don't want to support an extension that forces
clients to stop sending them in commands.

Also many existing clients could benefit a lot from NOTIFY, since their
"STATUS each mailbox every n minutes" could be replaced by a single
NOTIFY command. But if this same command requires rewriting their
command sending to use only UIDs, that could be a much larger job.

> > Some use cases for clients which want to keep using MSNs and IDLE:
> >
> > 1. Client just wants to use NOTIFY to see changes in other mailboxes, 
> > so it specifies NOTIFY SET (personal (messagenew messageexpunge)).
> 
> I assume the client still wants to immediately see changes in the 
> current mailbox? In this case it should also include (selected 
> (MessageNew MessageExpunge)) and things should work as before.

Not if it can't send MSNs in commands.

> > 2. Client wants to use NOTIFY to ignore annotation changes, so it uses 
> > NOTIFY SET (selected (FlagChange)).
> 
> FlagChange is tied to MessageNew and MessageExpunge, so this should 
> really be "NOTIFY SET (selected (FlagChange MessageNew MessageExpunge))"

And again it couldn't send MSNs in commands.

> > 3. Client wants to get pushed information about new messages' contents 
> > (MessageNew (uid ..)), but it still wants to keep using MSNs.
> 
> Can you elaborate on this use case?
> Your MessageNew already contains "uid", so clearly the client is already 
> capable of using UIDs anyway.

That was just an example. The fields could have been anything.

But anyway just because it uses UIDs in some places doesn't mean it even
could use UIDs everywhere. The best example is a Pine/webmail-like
application that fetches information only about the visible part of the
mailbox (in message list view). Those are the only kinds of IMAP clients
that are able to access huge mailboxes efficiently. In them when a user
scrolls a pageful up in message list, the client calculates how many
messages it needs to fetch and uses a FETCH with a sequence range. This
is impossible to do with UIDs unless the client fetches all UIDs, which
in turn makes it inefficient (especially with huge mailboxes) and waste
bandwidth for no good reason.

> > Since MessageNew and MessageExpunge must specified together, this is 
> > impossible .
> >
> > Is there even any other reason for client to even run IDLE unless it 
> > wants to keep using MSNs + see EXPUNGEs immediately? I think IDLE 
> > could be specified as sending EXPUNGEs immediately regardless of 
> > whether MessagExpunge has been specified.
> 
> I would rather not special case IDLE, so that we can keep server logic 
> consistent.
> In light of my corrected statement above, can you double check that 
> there is any issue?

If special casing IDLE made client able to send MSNs, I think it would
be useful to change it. But that also requires decoupling MessageExpunge
from other events.

> > 3. is also problematic. Is it really necessary to give MessageExpunge 
> > if MessageNew is given? The (well-behaving) servers already have to 
> > handle the case when a message is expunged and a new message arrives 
> > during FETCH/STORE/SEARCH command. The client is notified about the 
> > new message but not about the expunge.
> 
> True.
> The reason why we have MessageExpunge and MessageNew tied together is 
> because representative of a certain company kept moaning that he can't 
> implement them separately. The WG couldn't find any use cases where this 
> would make a difference for a client.

Again it makes sending MSNs impossible, which is bad.

I'd like it if all existing clients (which may be sending MSNs) could
easily replace their STATUS-polling with a single notify command:

1 NOTIFY SET (selected (MessageNew FlagChange) personal (MessageNew MessageExpunge))

Re: [lemonade] WGLC NOTIFY

Attachment: signature.asc