Comment 27 for bug 1712854

Thanks, Bill. There are a few reasons, some of them subjective, but one is behavioral.

First, subjectively, it provides a stable data set for paging, and reduces (in some workflows, significant) paging-induced server round trip time. Sorting (the full process of sort and render, that is) on the client side is much faster for a large data sets -- especially for smaller page sizes, as page render time far out strips in-browser sorting time -- and the main pain point is exactly those situations AIUI. It also reduces server load to a single call per filter change.

Behaviorally, the queue position calculation (which is always a lie, but we know that) is not reliable on paged sets. It depends on the full hold set to get right, numerically (and even then, still, it's a lie). However, we now have enough data (assuming appropriate configuration of the various hold wait estimation intervals) to calculate the estimated hold wait time on the client side, which would be a good enhancement to replace queue position.

Also of note is the fact that printing the full list becomes an O(n) operation, rather than refetching and rerendering. We have specific complaints about that in the hold shelf UI, and if we can move the hold pull list to this API then we'll all be tired of so much (printing) winning.