> I was thinking we could do it all client side with js and html5 (and > localstorage or indexdb) You'd define the order in system > preferences, local, google, amazon, ltfl etc. Then the js would try > them in that order and cache the resulting url (or the fact it > couldn't find one) in localstorage or indexdb, which persists even > when the browser is closed. That way it wouldnt need to be another > server/service, since you have the js already, it shouldn't be too > hard to convert it to an html5 client side app. Thoughts?
I understand and agree that having cover images URL as a service may have disadvantages. That's arguable. Thoughts: (1) Client-side storage may be insufficient. localstorage (and others) have size limits (~5MB): http://dev-test.nemikor.com/web-storage/support-test/ If URL have an average of 60 characters (120 bytes in UTF-16), for a 100,000 biblio records catalog (with ID), it means data URLs alone, without ID, may require as much as 12,000,000 bytes. Then, I'm not sure whereas localstorage has been designed to fetch quickly a value (URL) from a key (ISBN/EAN). On the contrary, Redis as a key/value store is very efficient. I don't know for IndexedDb. (2) There may be a security issue with AWS request done client-side. Request must be send to AWS with accessKeyId, secretAccessKey, and associateTag. It a security risk to send them to the client browser. (3) Technically, the AWS queries are sent by the node.js script using this library: https://github.com/livelycode/aws-lib As far as I know, there isn't an equivalent client-side. This library does a lot of stuff. AWS request and reply are complex: request has to be signed/encrypted, XML parsing is required, etc. So converting the node.js app to a client side app shouldn't be that easy. (4) A centralized cover URLs cache has several advantages: On a hosting plateform, as any Koha vendor has, a unique cover URL cache is easy to administer, and tweak. Centralized cached will grow quickly to contain 'all' useful URL. It could also be used outside Koha. _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
