Open Stack

On 15/08/2013, at 3:02 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/14/2013 12:25 PM, Mac Innes, Kiall wrote:
>> So, Are we saying that UIs built on OpenStack APIs shouldn't be able to
>> show traditional pagination controls? Or am I missing how this should
>> work with marker/limit?
> 
> No, not quite what I'm saying. The operation to get the total number of pages -- or more explicitly, the operation to get the *exact* number of pages in a list result -- is expensive, and in order to be reasonably efficient, some level of caching is almost always needed.
> 
> However, being able to page forwards and backwards is absolutely possible with limit/marker solutions. It simply requires the paging client (in this case, Horizon), to store the list of previously seen page links returned in listing results (there is a next and prev link in the returned list images results, for example).

Is there a prev link? It's optional in Compute v2 and Images v1 and Nova/Glance don't seem to be returning it. I suspect Nova v3 isn't either but I haven't tested it. There's no mention of it in Images v2 at all and no prev returned there either.

If there is a next and prev link in the returned results then Horizon wouldn't need to store anything - the links can be rendered straight into the page.

Anyway, you're right, this is all secondary to the need for decent filtering.

> 
>> e.g. for 11 pages of content, something like: 1 2 3 .. 10 11
> 
> Yeah, that's not an efficient operation unless you have some sort of caching in place. You can use things like MySQL's SQL_CALC_FOUND_ROWS, but that is not efficient since instead of stopping the query after LIMIT rows, you end up executing the entire query to determine the number of rows that *would* have been returned if no LIMIT was applied. In order to make such a thing efficient, you'd want to cache the value of SQL_CALC_FOUND_ROWS in the session and use that to calculate the number of pages.
> 
> It's something that can be done, but isn't, IMHO, worth it to get the traditional UI you describe. Instead, a good filter/search UI would be better, with just next/prev links.
> 
> Best,
> -jay
> 
>> Thanks,
>> Kiall
>> 
>> On 13/08/13 22:45, Jay Pipes wrote:
>>> On 08/13/2013 05:04 PM, Gabriel Hurley wrote:
>>>> I have been one of the earliest, loudest, and most consistent PITA's about pagination, so I probably oughta speak up. I would like to state three facts:
>>>> 
>>>> 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface.
>>>> 2. Pagination doesn't scale.
>>>> 3. OpenStack's APIs have historically had useless filtering capabilities.
>>>> 
>>>> In a world where pagination is a "must-have" feature we need to have page number + limit pagination in order to build a reasonable UI. Ironically though, I'm in favor of ditching pagination altogether. It's the lowest-common denominator, used because we as a community haven't buckled down and built meaningful ways for our users to get to the data they really want.
>>>> 
>>>> Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level "solutions":
>>>> 
>>>> Problem 1: I know what I want and I need to find it.
>>>> Solution: filtering/search systems.
>>> 
>>> This is a good place to start. Glance has excellent filtering/search
>>> capabilities -- built in to the API from early on in the Essex
>>> timeframe, and only expanded over the last few releases.
>>> 
>>> Pagination solutions should build on a solid filtering/search
>>> functionality in the API, where there is a consistent sort key and
>>> direction (either hard-coded or user-determined, doesn't matter).
>>> 
>>> Limit/offset pagination solutions (forward and backwards paging, random
>>> skip-to-a-page) are inefficient from a SQL query perspective and should
>>> be a last resort, IMO, compared to limit/marker. With some smart
>>> session-storage of a page's markers, backwards paging with limit/marker
>>> APIs is certainly possible -- just store the previous page's marker.
>>> 
>>>> Problem 2: I don't know what I want, and it may or may not exist.
>>>> Solution: tailored discovery mechanisms.
>>> 
>>> This should not be a use case that we spend much time on. Frankly, this
>>> use case can be summarized as "the window shopper scenario". Providing a
>>> quality search/filtering mechanism, including the *API* itself providing
>>> REST-ful discovery of the filters and search criteria the API supports,
>>> is way more important...
>>> 
>>>> Problem 3: I need to know something about *all* the data in my system.
>>>> Solution: reporting systems.
>>> 
>>> Sure, no disagreement there.
>>> 
>>>> We've got the better part of none of that.
>>> 
>>> I disagree. Some of the APIs have support for a good bit of
>>> search/filtering. We just need to bring all the projects up to search
>>> speed, Captain.
>>> 
>>> Best,
>>> -jay
>>> 
>>> p.s. I very often go to the second and third pages of Google searches.
>>> :) But I never skip to the 127th page of results.
>>> 
>>>   > But I'd like to solve these issues. I have lots of thoughts on all of
>>> those, and I think the UX and design communities can offer a lot in
>>> terms of the usability of the solutions we come up with. Even more, I
>>> think this would be an awesome working group session at the next summit
>>> to talk about nothing other than "how can we get rid of pagination?"
>>>> 
>>>> As a parting thought, what percentage of the time do you click to the second page of results in Google?
>>>> 
>>>> All the best,
>>>> 
>>>>       - Gabriel
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev