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

[Jason Etheridge]

On 12/29/06, Mike Rylander <mrylander at gmail.com> wrote:
> I know Jason has experimented some with paging vs scrolling as a run
> time option to the list building code.

The main thing I like about _not_ using paging is that it makes it
easier to sort and print complete lists, but in some cases (e.g.
z39.50 client) I have to resort to it.

> That's exactly how it's done in the staff client today.  The entire
> list of IDs (and IDs only) is retrieved, but only the visible rows are
> fleshed out.  With many hundreds or even thousands of rows, though,
> there's still a big performance hit in creating the dummy rows (which
> magically flesh themselves when they become visible).

Or rather, that's how it works ideally, but in practice we've been
moving back and forth between upfront and async retrieval of data, and
not every interface is doing that as well as it could.  In some cases
we're using chains of setTimeouts to stagger things, which was a
kludgy attempt at making things feel more "smooth".  Dynamically
creating placeholder rows isn't that bad, and I've experimented with
"pre-loading" n-dummy rows statically without much performance gain.

One problem is that though the list code supports async rendering, it
really only works with one async'ed network call per row.  I need to
revamp it to support multiple calls per row.  Right now we're using a
lot of "uber" retrieval methods that might return 4 or 5 objects for a
given "id".  I suspect things would be smoother with more async calls,
but I don't know where the sweet spot will end up falling given the
overhead for every function call, and every socket connection.

Another big annoyance is that I tend to regenerate entire lists
instead of just updating the pertinent row or rows when staff performs
an action.  For example, if staff renews one item directly from a
patron's Items Out list, I'll re-retrieve all of the circulations (and
all the other associated objects--call number, record summary, etc.)
I need to be more precise here (and re-work the code to support that).

> Paging is, I believe, where Jason is headed for interfaces where this
> is a common problem, and perhaps even on demand when there are more
> than, say, 100 rows.  There are other interfaces where a front line
> filter (filter by date or location, etc) would help out a lot.

They've definately asked for paging with Patron Search, and dislike
any arbitrary cap we come up with.  Filters will definately help with
such things as transit lists... things that have traditionally been
(and might still should be) "reports".

> One thing to consider, though, is that the sorting behavior is defined
> on the client side, and because the data shown is potentially from
> linked tables (sometimes several distant from the core object, and not
> necessarily predictable on the server in any case) sorting is not a
> simple thing to do on the server side.  I'm working on a cstore
> extension to address this issue (and others),

miker++

> but until that happens, the client will still need to fetch all the data in order
> apply a non-default sort.

And for some folks on some computers with some interfaces, that can
take minutes, and even after all the data has been retrieved, there
can be a noticeable delay with the actual sorting. :-/

[snip]
> Well, that's the thing.  We've been talking about list rendering, but
> I'm pretty sure that's not really involved here (again, Bill and Jason
> will need to chime in).

Yeah, you're right.  But I felt compelled to elaborate on the list
rendering anyway. :D

BTW, newer xulrunners seem to render lists faster and have a smaller
memory footprint.  I'll likely be pushing another beta out to
volunteer libraries soon.  Another thing affecting speed is that we're
using SSL for all staff client communication.  I need to start using
plain http for anything that doesn't need to be encrypted.

-- 
Jason Etheridge
GPLS -- PINES Development
http://open-ils.org/