Re: [Koha] Saving MARC records very slow
Salvete!
I find it totally undesirable to make or maintain any changes in the cataloging module for the purpose of going HTML-only.
Forgive me if I'm wrong, but my sense was that a change or changes would be made with paucity of code and processing time in mind. It was an optimisation suggestion.
advantage in actual environment constraints. Consider that adding a repeatable field would have to constitute a new request and response for each element, parsing the marcxl each time, aggregating form state changes in some yet undefined table. The server might validate
there just became 30 times as expensive and you still need to round
Your sense of server-side processing advantage may or may not translate to an the end results faster, but getting trip to the server to get the results.
Is that 30 times rooted in fact? Also, from what is being described, it seems as though the long wait for the record's finalisation would be traded for a few shorter waits upon edit. Do I have that right Rick?
I'd wager that exactly zero of our clients would prefer scriptless cataloguing, and would likewise be upset for Koha to sacrifice scripted features for it.
I'd reckon none of your clients would care if the job were done, and a whole bunch would be happier were the job done quicker. I don't think anyone was calling for a full sack of JS, just suggesting a well intended tinker to see if we can slim down an ugly just under a minute wait. Have you tried this your way Rick? I'd love to see side by side optimised versions to see what the pitfalls of both were.
Cataloging is already a huge amount of logic. Duplicating the plugins to operate cleanly as server-side validators would be a major undertaking in itself, and be more likely to introduce runtime warnings and fatals.
True, but I'm always all ears about making cataloguing better. What we have now is rather undesirable. I don't think anyone hinted that tinkering with or improving cataloguing was easy. :) For pros, (and it's been a while since I looked, so maybe this is implemented, but I don't think so) would it save querying time if there were a simple text box where one edited an entire MARC compliant or single original record? I didn't have a text box for every field with III, just a big old text box with a record. It seems to me as though this would shift the processing burden to the server, as well, and probably save time in the end. I realise the initial outlay of coding time would be substantial, but the friendliness to experienced users would most likely be worth it. Usability would be oh so much better, too. (I still need to find the right star to wish on for guided cataloguing for non pros :) ) Cheers, Brooke
Forgive me if I'm wrong, but my sense was that a change or changes would be made with paucity of code and processing time in mind. It was an optimisation suggestion.
The actual question was "Question: can Koha operate properly with JS disabled? If not, why not?" Depending on the poser, that question can either be genuine and neutral or it can be leading and accusatory. Posers, you know who you are ;)
Is that 30 times rooted in fact? Also, from what is being described, it seems as though the long wait for the record's finalisation would be traded for a few shorter waits upon edit. Do I have that right Rick?
I think "30 times" should be considered an estimate. It depends on how much you're editing your record. How many times might one: - add a tag - delete a tag - add a subfield - delete a subfield - use any plugin What am I leaving out? Instead of having one longer wait at the end, you're having 30 (or whatever) waits while you're performing any one of these actions.
I'd reckon none of your clients would care if the job were done
And unfortunately that means none of them would sponsor it.
I don't think anyone was calling for a full sack of JS
I know some do! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
UM, I use Firefox and I don't have a problem with time for saving records (a few seconds at most). And I do a lot of them as I'm still cleaning up our switch from InMagic. Yes, I'm on 3.00 (not sure exactly which) Lenora Lenora A. Oftedahl StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
BWS Johnson wrote:
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? Also, from what is being described, it seems as though the long wait for the record's finalisation would be traded for a few shorter waits upon edit. Do I have that right Rick?
Correct. 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. Example: some of the Koha searches update a textbox / dropdown control with new search possibilities each time you hit a key on the keyboard. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Debra Jackson says she likes shopping at the Dollar Palace because it's convenient and casual. "I don't have to get dressed up like I'm going to Wal-mart or something," she said. -- spotted in a newspaper
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
participants (5)
-
BWS Johnson -
Joe Atzberger -
Lenora Oftedahl -
Owen Leonard -
Rick Welykochy