Open Bug 673370 Opened 13 years ago Updated 2 years ago

Index messages which are not stored offline using IMAP BODYSTRUCTURE

Categories

(MailNews Core :: Database, defect)

defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: protz, Assigned: protz)

Details

This is for IMAP folders which are not stored offline.

Right now, I'm pretty sure Gloda only uses the information stored in the nsIMsgDBHdr to perform its indexing. Now the JS Mime Emitter has gained the ability to use BODYSTRUCTURE, I think we could take advantage of that to index the message using the results of BODYSTRUCTURE, and not just use the msf information.

One big win is that Gloda would now be aware of attachments for messages that are not stored offline (right, it isn't aware of them).

:bienvenu, do you see any objection to this?
No objection per se, but I'd really like to see it combined with an attempt to get messages from the necko cache first (either the memory or disk cache). This would avoid unneeded network traffic. Doing a normal message fetch will use the necko cache first, and avoid any network traffic, but asking for body structure will require talking to the imap server, even if we have the message in the necko cache.

nsImapService::IsMsgInMemCache will tell you if a message is in the necko cache (memory or disk; the cache used to be memory only, but has been changed to include disk, w/o changing the method names - this is distinct from the offline store).

Newly downloaded messages, either by the junk filter, or the user reading them, will very likely be in the necko cache. Older messages are much less likely to be in the disk cache.
Noting that gloda should honor our rule that "don't store offline" === "don't fulltext index the body" if we do end up streaming the message because it's fully available.

Good simplifying news is that because gloda listens for msgsClassified events and therefore strictly happen after the junk filter, the cache should already have the message (as long as it's big enough to hold on).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.