Re: [SM-DEVEL] Unique Mailbox State Identifier?

[Robin R. <ro...@ra...>]

Yup - I wanted to know if we could detect any change at all, in any of the
folders in a mailbox with just one command.

Someone almost guessed why I wanted this earlier. See, if we could do
that, then you could have a 'hidden' page in the SM frameset that was tiny
and refreshed more often, and only when it detects a change in the mailbox
it would cause the left frame to refresh (which also causes the right one
to if you have folder_sync installed).

I would like to see this, because it would place a smaller load on your
server (it would be a very small refresh) more often, then the overhead of
having to re-display the whole folder list all the time. Well, this is the
idea anyhow. Basically, I want a nicer and faster way to see when new
messages arrive. Are we thinking of any fancy java/dhtml/etc. stuff that
could go on in the left frame and save the whole thing refreshing unless
absolutly necessary?

Ooops... I'm thinking aloud now, not so good with my warped mind ;-)

Robin

Dave Cridland [Home] said:
> On Sun, 2003-03-09 at 02:01, Marc Groot Koerkamp wrote:
>> It's just a matter of probability that a mailbox is changed. It's
>> important for caching mailbox headers. Flags are not that important.
>
> Ah, I got the impression from Robin's original mail he wanted to know
> any change at all.
>
> For a header cache, you simply need UIDVALIDITY, UIDNEXT, and MESSAGES,
> as you said. No need to perform a FETCH at all unless those have
> changed. But flags can change, and ought to be assumed to have done so.
> Robin specifically asks for flag changes to be included.
>
> Incidentally, Robin's request *is* possible with an IMAP server
> supporting CONDSTORE (Conditional Store), which is still in draft. I
> hadn't read through that draft in detail before.
>
> You might find this as a compile-time option defaulting to off in Cyrus
> and/or UW - I know Cyrus has the Annotate extension hiding away. Either
> way, you probably don't want to use it yet.
>
> Oh, and this doesn't support scanning inferior mailboxes for you either,
> but as I said before, hierarchy is considered distinct from contents in
> IMAP.
>
>> > The only way I can immediately think of for detecting any change in
>> status would be looking at UIDVALIDITY and UIDNEXT (as discussed)
>> followed by a UID FETCH 1:<current uidnext> (FLAGS) with the
>> relevant mailbox selected and comparing it to the cache, which
>> wouldn't tell you anything about the inferior mailboxes.
>> Correct, and use MESSAGES because combining it with UIDNEXT you detect
>> if messages are deleted (expunged)
>
> You would anyway with the rescan using FETCH above, since you'd see
> holes in the range.
>
>> > Don't you just love pathological cases?
>> Hehe, I'm not advogating you can detect every change, I only mentioned
>> what you can detect.
>
> Which is surprisingly close to nothing, definitively, without rescanning
> the mailbox to some degree.
>
> Dave.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger  for complex code. Debugging C/C++ programs can leave you
> feeling lost and  disoriented. TotalView can help you find your way.
> Available on major UNIX  and Linux platforms. Try it free. www.etnus.com
> --
> squirrelmail-devel mailing list
> List Address: squ...@li...
> List Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=7139 List Info:
> https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel