798667 - X-GM-LABELS should be checked more frequently for updates

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[David Lechner (:dlech)]

Followup bug to item 8 on https://bugzilla.mozilla.org/show_bug.cgi?id=721316#c60

Currently, X-GM-LABELS is only read from the server when the message header is read. However, X-GM-LABELS change at any time. For example, if a user changes labels in the gmail web interface, the changes should be updated in thunderbird as soon a posible. I think the best way to do this would be to fetch X-GM-LABELS whenever you fetch FLAGS.

Comment 1

[Atul Jangra [:atuljangra]]

Confirming the bug.

Comment 2

[David :Bienvenu]

I'm not sure this would matter much for helping to avoid downloading a message body multiple times, since it's mostly newly downloaded headers that we want to download for offline use. But, if there's UI that displays the x-gm-labels, then keeping them up to date is more important. Is that your primary concern, David?

Comment 3

[David Lechner (:dlech)]

Yes, I am thinking about UI / extensions using the labels for informational purposes - as in bug 800010.

Comment 4

[Atul Jangra [:atuljangra]]

For the record, necessary changes are required in function defined here https://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#3988 . We'll fetch the labels from X-GM-LABELS and then update corresponding value in hashtable. (http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapFlagAndUidState.cpp#325)

Comment 5

[Atul Jangra [:atuljangra]]

David(dlech), I was having different views about this. I discussed it with David Bienvenu. We agreed that this will make opening large gmail folder more expensive, both for bandwidth and server load. Thus maybe we can control this with a hidden pref, defaulted to false, and let the user decide what he wants. Also on the other hand, we can just use your extension directly for fetching X-GM-LABELS. Extension will be also useful in Bug 800010.

we also have CONDSTORE/QRESYNC (http://tools.ietf.org/html/rfc5162) for similar kind of stuff. But I am not sure how to use them properly. :-s

Comment 6

[David Lechner (:dlech)]

(In reply to Atul Jangra [:atuljangra] from comment #5)
> David(dlech), I was having different views about this. I discussed it with
> David Bienvenu. We agreed that this will make opening large gmail folder
> more expensive, both for bandwidth and server load. 

I am with you there.

> Thus maybe we can
> control this with a hidden pref, defaulted to false, and let the user decide
> what he wants.

A 3rd option is to only fetch flags for the currently selected message. This is what I am doing in my extension. There is a slight delay before the labels show up when you select a message, but it gets around the problem of fetching labels for an entire folder.

> Also on the other hand, we can just use your extension
> directly for fetching X-GM-LABELS. Extension will be also useful in Bug
> 800010.

This is certainly a viable option as well.

> 
> we also have CONDSTORE/QRESYNC (http://tools.ietf.org/html/rfc5162) for
> similar kind of stuff. But I am not sure how to use them properly. :-s

Gmail does not have the QRESYNC capability advertised at the moment, so this is not an option - unless you know something that I don't.

Comment 7

[Atul Jangra [:atuljangra]]

(In reply to David Lechner (:dlech) from comment #6)
> A 3rd option is to only fetch flags for the currently selected message. This
> is what I am doing in my extension. There is a slight delay before the
> labels show up when you select a message, but it gets around the problem of
> fetching labels for an entire folder.

Yes, this can be a case, but do we need to discuss this with someone, before doing this?

> 
> > Also on the other hand, we can just use your extension
> > directly for fetching X-GM-LABELS. Extension will be also useful in Bug
> > 800010.
> This is certainly a viable option as well.
yes, this will always be a viable option :-)
> > we also have CONDSTORE/QRESYNC (http://tools.ietf.org/html/rfc5162) for
> > similar kind of stuff. But I am not sure how to use them properly. :-s
> 
> Gmail does not have the QRESYNC capability advertised at the moment, so this
> is not an option - unless you know something that I don't.
Yes you are right here. :-)

Comment 8

[David Rees]

Note that getting the X-GM-LABELS on a per message basis will not properly support viewing them at the list level as I mention in https://bugzilla.mozilla.org/show_bug.cgi?id=800010#c13.

Comment 9

[David Rees]

Per message also would not properly support X-GM-LABELS filters/searches as requested in bug #871200.

Comment 10

[WADA:World Anti-bad-Duping Agency]

FYI.
Because Gmail IMAP already supports CONDSTORE, if bug 1123094, bug 1123617, bug  1124569, bug 1124924 will be fixed, this bug will be resolved merely by "Flags => Flags X-GM-LABELS" in imap command for re-sync, new mail check..  

Even when CONDSTORE/QRESYNC is not usable, X-GM-LABEL should be fetched upon resync/new mail check.
    resync(folder open, upon select for new mail check/downlod)
        SELECT Mbox, uid fetch 1:* Flags   => SELECT Mbox, uid fetch 1:* Flags X-GM-LABELS
    new mail check at cached connection when Mbox is selected
        uid fetch NextUID:* Flags   => uid fetch NextUID:* Flags X-GM-LABELS
        Because state of HIGHEST UID is returned by NextUID:*, Tb can know state change of newest mail.

When CONDSTORE only. (Gmail already supports CONDSTORE)
    resync(folder open, upon select for new mail check/downlod)
        SELECT Mbox, uid fetch 1:* Flags   => SELECT Mbox, uid fetch 1:* Flags X-GM-LABEL
    new mail check at cached connection when Mbox is selected
        uid fetch NextUID:* Flags   => uid fetch 1:* Flags X-GM-LABEL (CHANGEDSINCE known_modseq)
    Note-1: Bug 1124924 is needed. For CONDSTORE support, see Bug 912216, please.
    Note-2: For knowing flag state change, CONDSTORE + "uid fetch 1;* (CHANGEDSINCE ...)" is sufficient.
                  QRESYNC is needed for correct && efficient EXPUNGE state tracking. Without QRESYNC, "efficient" part is lost if "correctness" is needed.

When CONDSTORE + QRESYNC
    first Mbox use after account definition
         SELECT Mbox, uid fetch 1:* Flags X-GM-LABEL
    resync(folder open, upon select for new mail check/downlod)
         SELECT Mbox, SEARCH ALL, uid fetch x:y Flags X-GM-LABEL (CHANGEDSINCE known_modseq)
    new mail check at cached connection when Mbox is selected
        uid fetch 1:* Flags X-GM-LABEL (CHANGEDSINCE known_modseq)