Topic on Extension talk:CirrusSearch/Query Construction/Use cases

It seems like "A dispatch service that select multiple best routes with tabbed search results" is the option that provides the greatest flexibility. I noticed that it only "may" break the following use cases. Would you please clarify why that is?

• 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
• As a client of the search API I want to be able to do everything that is done in Special:Search[1].

Also, I gather that while this says "tabbed" search results, this isn't necessarily suggesting that in fact such a UX change must happen, only that it would become possible, is that right?

I will clarify this point in the page but here is a short answer:

From a backend perspective the search system is accessed either from Special:Search using PHP internal apis or from MW API clients. Until now these internal APIs all provided a single list of results for the current wiki results.

Assuming we decide that mixing different content-types in the same set of results is something we no longer want to support we will break this usecase:

- 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

Secondly, assuming we provide a tabbed search interface through Special:Search we will have to provide new formats for the search API response and why we may break the second usecase you mention if we only focus on Special:Search and the internal PHP search APIs.

When I write "may" it should probably be read as: some specific efforts will have to be made to keep these usecases intact.

And I completely agree with your conclusion that says: tabbed search results might be a possible option that fits most of the usecases we would like to support (esp. when mixing different content-types) but it should not be mandatory.

I will try to rephrase this a bit more.

Thanks for your inputs!

I also like the tabbed search idea, with different namespaces in each tab

Do users really care about how many results are returned?

I'm sure some bots will just scan the number of total hits, it's why I think we still need to support (in the backend) a way to query everything even if it's not using the best components (provided by extensions).