[Koha-devel] Amazon Cover Images

Frédéric Demians frederic at tamil.fr
Thu Feb 7 16:49:01 CET 2013


> 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.




More information about the Koha-devel mailing list