[Koha] Saving MARC records very slow

[Joe Atzberger]

> >> there just became 30 times as expensive and you still need to round
> >> trip to the server to get the results.
> >
> > Is that 30 times rooted in fact?
>

It isn't implemented, so it is hypothetical, but there isn't any way around
*every* operation requiring a round trip to the server w/o js.  Do some
original cataloging, count how many times you change tabs, search for an
authorized value, and add/remove fields.


> It is disingenuous to whine about return trips to the server when
> Koha is already littered with such in the form of Ajax calls, which
> sometimes for each keystroke invoke a return trip to the server.


Uh, no.  It's legit.  Especially on the staff side, Koha would benefit from
*more* ajax, not less.  When the logic of a webapp can be broken into
ajax-able atomic pieces, then each of those can execute and reply with very
small updates without having to reparse everything else on the page that
isn't changing.

As a simple (hypothetical) example, building a list gets really expensive if
you have to read out the growing list AND all the other elements of the page
to the client for every item loaded.  With ajax you can get confirmation
from server as terse as one line.  The non-ajax method doesn't scale.  It
gets slower as the list gets bigger until the point where it is too slow to
use.  The ajax method can maintain the same performance at the 1000th
request as the first, because it doesn't have to care about the last 999.

Example: some of the Koha searches update a textbox / dropdown control with
> new search possibilities each time you hit a key on the keyboard.


Those YUI autocomplete calls aren't parsing MARCXML into MARC::Record
objects like the cataloging editor must, and they can already be disabled by
syspref.  YUI autocomplete performs reasonably well for us and the thousands
of other sites that use the package.  And, lastly, ajax has nothing to do
with the cataloging editor anyway.  It doesn't use it.

You are comparing two clearly different entities.  HTML-only cataloging with
anything approaching the current features would require repeated expensive
MARC parsing, aggregating the cataloger's manipulations in an unspecified
location, all the existing permissions checking for toolbars and
HTML::Template::Pro building, etc.  That looks nothing like optional
industry standard AJAX autocomplete that hits ysearch.pl, querying one table
and running in 60 lines.

-- 
Joe Atzberger
LibLime - Open Source Library Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20090630/6880f389/attachment.htm