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.

Confirming the bug.

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?

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

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)

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

(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.

(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. :-)

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.

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

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)