Extension:CirrusSearch/Query Construction/Use cases

The question to answer here is: how extension may augment CirrusSearch to let it search the data (new ContentType/metadata) provided by the extension in an efficient way.

Use cases

 * 1) As an extension developer I want to customize everything related to the search query for a specific namespace/query
 * 2) As an extension developer I don't want to care about searches in other namespaces, I assume CirrusSearch will provide good defaults
 * 3) As an extension developer I want my search query builders to be used if the namespaces requested is part of the requested namespaces
 * 4) As an extension developer I don't want another extension to hijack my search query builders
 * 5) As a client of the search API I want to list/count all pages that match my search query and I sometimes don't really care about the ideal search query builders/results ranking
 * 6) As a client of the search API I want to be able to do everything that is done in Special:Search.
 * 7) As an extension developer I want to customize the content/information displayed on every search result
 * 8) As a user of the search UI I may find confusing to see mixed kind of metadata shown in the search results
 * 9) As a user of the search UI I want the default search settings to be the best settings available
 * 10) As a user of the search UI I want the best settings to be easily available and/or to have messages that indicate that better options are available

A dispatch service in CirrusSearch that selects one best set of builders
This is the first solution attempted in. Cirrus applies a set of routes and keep the best one.

This solution breaks:
 * Usecase 10: when selecting incompatible namespaces provides a sub-optimal search experiences without notice.
 * Usecase 9: depends solely on the wiki-configuration, namespaces searched by default must be inline with the profiles available

Pros: Cons:
 * Easy to implement
 * No UI changes
 * Some usecases not respected

Cirrus able to combine multiple query builders in a single search query
Hypothetical solution where Cirrus would find a way to combine all best query builders in a single query. The result sets would contain mixed types of result.

This solution breaks:
 * Usecase 7 or 8, because we provide in the same set different kind of results.

Pros: Cons:
 * May be able to use optimal ranking in all cases
 * Some usecases not respected
 * Extremely hard to implement (combine multiple queries with score normalization issues)

Current solution
The current solution is implement a hook that allows an extension to override the current query builder on the fly.

This solution breaks:
 * Usecase 4: extensions may compete with each others in a manner that is almost impossible to control (hook registration order)
 * Usecase 5: as an extension may decide arbitrarily that its namespace is better than the others and exclude them from the search query

Pros: Cons:
 * Works for wikidata so far
 * Some usecases not respected
 * Prevents further refactoring in cirrus as it relies on manipulating the SearchContext

A dispatch service that select multiple best routes with tabbed search results
This solution may break:
 * Usecase 5 or 6

Pros: Cons:
 * May provide the user of the search UIs all information needed to clearly select the kind of results they prefer
 * Requires heavy UI changes
 * Some usecases may not be respected