[OPEN-ILS-DEV] Discussion on bulk loan procedures/options/suggestions to outreach "patrons"

[Nathan Eady]

Don McMorris wrote:

> One method I have thought of that may accomplish the goals is to limit
> the results and split it among different pages.  In the PAC (for
> example), searches resulting in numerous items will be split among
> different pages w/, say, 25 items per page.

That was my immediate thought.  There's limited space on the screen
anway, so the bare minimum the user is going to have to do is scroll
in order to see them all.  There's no getting around that the user
will have to take _some_ action, not with hundreds or potentially
thousands of items on the list (assuming we don't want to scroll
the list across the screen at lightning speed like in the movies).
Could the list be propagated lazily and/or asynchronously, allowing
the patron record to be shown before they're all retrieved, and only
blocking if they're actually needed (e.g., if the user hits "renew
everything" or tries to scroll to the bottom of the list)?  That
at least would push back the performance hit from retrieving and
showing the list to only situations where the list is actually
needed.

And if you're going to propagate lists lazily on patron records,
why not in other places as well?  Say I bring up a bibliographic
record for an extremely popular book, and there are a thousand
items attached to it.  (Only a very large library system could
have that many, and only for very few books, but it's not an
inconceivable situation.)  Wouldn't the same interface be suitable
there as well?  Why not just propagate *all* lists lazily, using
a standard piece of list-loading infrastructure?

(The question of why retrieving a mere 700 records causes a
user-noticeable delay is another matter, but perhaps it's the
placement of them in a display widget, rather than the retrieving,
that causes the issue.  I'm afraid I don't know OpenILS well enough
yet to know if I have even made sense here on that particular.)