Enhance horizon's filtering capability by enabling multiple filters

[jpomero 2014-09-16]
I like the idea of performing the filtering within horizon, simply because we can be consistent across all the tables and not rely on API capabilities which might never be consistent. It would mean we can provide a great complex filtering mechanism for multiple fields at the same time. One concern with this approach is paging. The reason we went to API filtering for the paged tables (currently images and instances) is because paging is already done through the API and in order for the filter to be correct when there are multiple pages is to also perform the filtering in the API. So basically if we move filtering to horizon we also need to move paging to horizon, or drop paging altogether. I *think* I like the idea of dropping pagination in favor of good filtering. This is the approach keystone v3 API has taken, where they support multiple filter types but do not support paging. The implementation of the keystone v3 API filtering that I have proposed (see bug 1321483) introduces a configurable table row limit setting so that horizon doesn't try to render thousands of rows and bring the browser to its knees. I bring this up because it's a possible approach that could be taken for all tables, therefore removing the paging issue from the picture.

[jacalcat 2014-09-17]
Can you clarify "Configurable row limit"? Are you proposing that paging is still done in Horizon, but all the data is managed in the browser? Will that work with a wide range of browsers, memory sizes and network speeds?

[2014-11-17 | david-lyle] This would indeed be very helpful, supposing the server side APIs support multiple filters. Please update to add more information using the approved template for Horizon in Kilo: [2014-11-17 | david-lyle] greater support and better UX around heat are a priority. Please update the blueprint to use the approved blueprint template for Horizon in Juno:
https://blueprints.launchpad.net/horizon/+spec/template