Open Stack

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).

> 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
>>