Mark Crispin wrote:
As you noticed, none of the current mailbox formats used by UW imapd are
particular ameniable to doing poll-type notification. At least in part
this is due to legacy. However, with delivery-initiated notifications,
there is no need to do polling or to have special format considerations
for notification.
I still think it would be very useful to have support for a state where
results are returned very quickly (near constant time with respect to
number of messages or size of mailbox) in the case that 'nothing has
changed since last time.' Even with a notification mechanism,
wholescale synchronization must happen every now and then, such as
whenever the mail client is started.
For users like myself who have many mail folders that may not have
changed since the last access, it would be nice if this initial
synchronization could happen quickly, rather than the 3-4 minutes it
takes me. (In my case, this time is solely spent reading MBX files;
there is no appreciable network latency or bandwidth limitations.)
I actually developed a prototype version of a protocol and software that
did this, but that project got shelved. More recently, the IETF
Lemonade Working Group has considered the question of notification, and
a hack (RFC 4146) to do this has actually been published as an RFC.
They are actually chartered to do this work, see item 4 of:
http://www.ietf.org/html.charters/lemonade-charter.html
I suppose there is also the classical biff/comsat mechanism. I guess my
next step is to see what it takes to get Mozilla to accept new mail
notifications from external sources (other than polling). It seems like
it would be easy enough to have procmail, or whatever, generate a
notification of some sort when it delivers mail, before passing off to
dmail.
Aaron W. LaFramboise
_______________________________________________
Imap-uw mailing list
[EMAIL PROTECTED]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
