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 are part of the namespaces I support
 * 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 multiple types of search results (e.g. tabs/sections)
The reasoning here is to say: if it's a limitation of the backend not being able to adapt to the current search UX we should focus on the solution where cirrus is able to combine everything in a single query and a unified search results list.

or:

We could also see the problem as being tightly coupled with the UX hence this solution.

The root of this solution is to say that when different content types are mixed in a wiki and when the search system have specific tunings for these different content-types (through custom extensions) the UX should be aware of this and don't assume that the backend is only able to send a single unified list of results.

If the UI wants to take benefits of the best possible options provided by the search backend it must adapt itself in such a way that the user is aware that multiple ranked lists of search results are available.

Pros: Cons:
 * may allow to support all usecases (assuming changes in the APIs)
 * does not fit into current UX