Subject: RE: [Lemonade]About draft-gulbrandsen-imap-notify-01

From: Dave Cridland <[email-masked]>
Date: Wed, 22 Nov 2006 12:04:29 +0000

On Wed Nov 22 10:55:31 2006, Ben Last wrote:
> >From: Arnt Gulbrandsen [mailto:[email-masked]] >Should NOTIFY send 
> an immediate STATUS (UIDNEXT HIGHESTMODSEQ) the
> first time it's run?
> >(The server has to know whether it's the first time, 
> unfortunately.)
> 
> > [ useful examples snipped ]
> 
> I think that's an excellent idea; it allows the client to see,
> immediately after login, what the current modseq and uidnext of all
> mailboxes is, and that allows it to determine immediately whether
> anything has changed in those mailboxes since the last time it was
> synchronized.  Loss of synchronization due to loss of network 
> connection
> is, after all, inevitable in mobile.  Thus I imagine that any client
> would want to know the status, so it's efficient to have it provided
> automatically.

Yes, but it's also pipelinable, so as Arnt points out, the overhead 
of the client doing it is slight, and the complexity for the server 
is comparitively great, especially if we consider multiple NOTIFY 
commands (should the server issue STATUS for only those mailboxes 
previously not set to NOTIFY?).

FWIW, using a fresh deflate stream, Arnt's example commands 
compressed to 37 octets when the client issued "A01 NOTIFY (mailbox1 
mailbox2) ...\r\n", and 81 octets when the client issued "A01 NOTIFY 
(mailbox1 mailbox2) ...\r\nA02 STATUS mailbox1 (HIGHESTMODSEQ 
UIDNEXT)\r\nA03 STATUS mailbox2 (HIGHESTMODSEQ UIDNEXT)\r\n". This 
isn't terribly useful, since it's a fresh deflate stream, although 
it's using a Z_SYNC_FLUSH, but it might suggest that the overhead of 
the client issuing the STATUS commands explicitly is higher than Arnt 
suspected.

Overall, I'm very much open-minded about the issue for now, and I 
think I'd prefer to gain some implementation experience first.

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

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 22 Nov 2006 13:14:24 +0100

Dave Cridland writes:
>> >From: Arnt Gulbrandsen [mailto:[email-masked]] >Should NOTIFY send an 
>> immediate STATUS (UIDNEXT HIGHESTMODSEQ) the
>> first time it's run?
>> >(The server has to know whether it's the first time, unfortunately.)
>>
>> synchronized.  Loss of synchronization due to loss of network connection

(What? I didn't see that message?)

> Yes, but it's also pipelinable, so as Arnt points out, the overhead of 
> the client doing it is slight, and the complexity for the server is 
> comparitively great, especially if we consider multiple NOTIFY 

*IF* this is a good idea, then the rule is simple: It applies only for 
the first NOTIFY command.

Because the server's pre-NOTIFY default cannot be expressed using 
NOTIFY, the server has to keep track of whether a NOTIFY command has 
been issued before. Sending the STATUS responses should be less than 
ten lines of code conditioned by an existing variable. Or two existing 
variables. Any other rule would be much more complex and not much 
better.

> FWIW, using a fresh deflate stream, Arnt's example commands compressed 
> to 37 octets when the client issued "A01 NOTIFY (mailbox1 mailbox2) 
> ...\r\n", and 81 octets when the client issued "A01 NOTIFY (mailbox1 
> mailbox2) ...\r\nA02 STATUS mailbox1 (HIGHESTMODSEQ UIDNEXT)\r\nA03 
> STATUS mailbox2 (HIGHESTMODSEQ UIDNEXT)\r\n". This isn't terribly 
> useful, since it's a fresh deflate stream, although it's using a 
> Z_SYNC_FLUSH, but it might suggest that the overhead of the client 
> issuing the STATUS commands explicitly is higher than Arnt suspected.

I wonder why.

> think I'd prefer to gain some implementation experience first.

Sounds good to me.

Btw, I finished editing of -02 this morning and once Curtis, Alexey and 
I agree on the changes (that may require some more editing) I'll post 
it.

Arnt
typist

---

From: "Ben Last" <[email-masked]>
Date: Wed, 22 Nov 2006 14:57:39 -0000

>From: Dave Cridland [mailto:[email-masked]] 
> mailboxes is...
the client doing it is slight,
>and the complexity for the server is comparitively great, especially if
we >consider multiple NOTIFY
previously not set to NOTIFY?).
Actually, I've always considered pipelining of commands to be a
complexity in a client; we tend to avoid it because it makes the
implementation of a state machine potentially much more complex.  But
yes, I ignored any implications for the server.  That's the good part of
doing client development :)

Regards
Ben

Ben Last
R&D Manager
EMCC Software Ltd