Open Bug 523649 Opened 10 years ago Updated 8 years ago

Support per-folder gloda index suppression in backend

Categories

(MailNews Core :: Search, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: rkent, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Add an inherited folder property to allow extensions in TB 3.0 to suppress gloda indexing on a per-folder, per-folder-tree, or per-server basis.

The suppression is easy, what is hard is the notifications. Perhaps it would be sufficient, in the TB 3.0 timeframe, to just do what is easy, which would then require a restart to enable the changes. This is not something people will be changing frequently anyway.
I don't know what is happening with asuth's refactoring at the moment, but this shows the minimum that I would like added before TB3. WIP GlodaQuilla extension to follow that shows how this is used.
Attachment #407647 - Flags: review?
Attachment #407647 - Flags: review? → review?(bugmail)
This is a WIP of a new version of GlodaQuilla that uses the new inherited property. The property shows up in the General tab of the folder properties dialog. I would also implement something like this at the account level, so that indexing could be disabled for an entire account.
I should note that the extension as written will work even without this patch, by overriding the existing shouldIndexFolder on indexer.js
Whiteboard: [needs r asuth]
As expected, I've bit-rotted this a bit.  The changes to consolidate logic into shouldIndexFolder should have already been effected mainly leaving the additional logic for shouldIndexFolder and the proxying exposure of it to Gloda.  (And now the message indexer is GlodaMsgIndexer in index_msg.js.)

I'm slightly torn as to what-to-do in regards to the patch given that:
- The extension can implement all required logic without changes to the core
- The patch doesn't detect / handle the transition case and could use tests
- Because I waited on the gloda correctness patch which took way long, I likely
   prevented the previous point from being addressed by rkent (although I did
   raise my desire for event-driven stuff in our IRC conversations).  Sorry! :(

Anywho, I think the right course of action is probably just for GlodaQuilla to wrap shouldIndexFolder and provide the logic itself.  The wrapper function can check the inherited value and iff it is "false", return false.  Otherwise it must call the real shouldIndexFolder and return what it returns.  Under no circumstances should it return true of its own accord.

My rationale is generally that since it can be done without help from the core and the patch for the core is not the ideal end-state (in the sense of handling the events and triggering purges/reindexing) with tests, we might as well leave all of this in the extension.

rkent, if you want to pursue the solution that involves events and such, there may be time for that and I can be much more responsive now that I'm no longer on vacation and the gloda correctness patch is done.
Attachment #407647 - Attachment is obsolete: true
Attachment #407647 - Flags: review?(bugmail)
Whiteboard: [needs r asuth]
Duplicate of this bug: 545521
I haven't looked at this in ages, so I'll remove my assignment.
Assignee: kent → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.