<div dir="ltr">2013/8/14 Kieran Spear <span dir="ltr"><<a href="mailto:kispear@gmail.com" target="_blank">kispear@gmail.com</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
On 14/08/2013, at 7:40 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
> On 08/13/2013 05:04 PM, Gabriel Hurley wrote:<br>
>> 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:<br>
>><br>
>> 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface.<br>
>> 2. Pagination doesn't scale.<br>
>> 3. OpenStack's APIs have historically had useless filtering capabilities.<br>
>><br>
>> 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.<br>
>><br>
>> Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level "solutions":<br>
>><br>
>> Problem 1: I know what I want and I need to find it.<br>
>> Solution: filtering/search systems.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> 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.<br>
<br>
</div>Not just the previous page's marker, but the marker of every previous page since we would like to be able to click the previous button more than once. Any previous markers we store are also likely to become stale pretty quickly. And all this is based on the assumption that the user's session even started at the first 'page' - it could be they followed a link from elsewhere in Horizon or the greater internet.<br>
<br></blockquote><div style>I think we don't have to store previous pages' markers. Just storing current page's markers is OK. Nova or Glance has supported 'sort_dir' for long, if you want to go to the previous page, just use the first entry of current page as marker and set sort_dir as 'asc'; Otherwise, use the last entry of current page as marker and set sort_dir as ‘desc’.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I completely agree with Dolph that this is something the client shouldn't need to care about at all. The next/prev links returned with each page of results should hide all of this. next/prev links also make it trivial for the client to discover whether there's even a next page at all, since we don't want to make a user click a link to go to an empty page.<br>
<br>
Having said that, I think we can improve the current marker/limit system without hurting performance if we split the marker into 'before' and 'after' parameters. That way all the information needed to go forward or backwards is included in the results for the current page. Supporting 'before' should be as simple as reversing the sort order and then flipping the order of the results.<br>
<span class=""><font color="#888888"><br>
<br>
Kieran<br>
</font></span><div class=""><div class="h5"><br>
<br>
><br>
>> Problem 2: I don't know what I want, and it may or may not exist.<br>
>> Solution: tailored discovery mechanisms.<br>
><br>
> 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...<br>
><br>
>> Problem 3: I need to know something about *all* the data in my system.<br>
>> Solution: reporting systems.<br>
><br>
> Sure, no disagreement there.<br>
><br>
>> We've got the better part of none of that.<br>
><br>
> 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.<br>
><br>
> Best,<br>
> -jay<br>
><br>
> 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.<br>
><br>
> > 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?"<br>
>><br>
>> As a parting thought, what percentage of the time do you click to the second page of results in Google?<br>
>><br>
>> All the best,<br>
>><br>
>> - Gabriel<br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>