leonardr
commented
8 years ago Talking with Amy uncovered a number of significant complications in this approach:
- For all cases that currently result in the patron being sent an error, the error needs to be stored in the database, included as part of the patron's
/loansfeed, and properly rendered in the client interface among other successful and unsuccessful loans and holds. - If you remove a hold and immediately place it again, you should not lose your place in line--the whole operation should be cancelled.
- Borrowing or fulfilling an Overdrive loan requires the patron's credential. We can refresh the credential when the patron first asks to borrow the book, but assuming Overdrive is working properly (as it generally is) it's then not much of an additional wait time to actually borrow the book. If we get into a situation where there's an unfulfilled Overdrive loan and the credential is expired, there's nothing we can do until the patron makes another authenticated request, at which point we should also refresh their Overdrive credential (even if their request has nothing to do with Overdrive). In the meantime it's possible that another patron with a working credential might jump the queue and get the book they should have to wait for.
- We shouldn't fetch the ACSM files for 3M books, even though in almost all cases it will save time, because 3M can't regenerate ACSM files. To maximize the chance that 3M books can be fulfilled, we should bypass this system and only request the ACSM file once the patron actually asks for it.
For these reasons we're putting this work on hold. There are too many edge cases and weird behaviors.
Currently all loan-related operations are processed 'live'. This means that patrons are 'kept on the phone' while we go out to the API provider and process the following operations:
Possibly others I'm forgetting.
If the API provider is slow or broken, this leads to very bad experiences for the patron. Furthermore, since reading a book involves two API calls ('borrow' and 'fulfill') that nearly always happen in immediate sequence, there's usually a little bit of wasted time in the process.
If loan fulfillment was done asynchronously, the wasted time should mostly go away. If fulfilling a loan is fast, there's a good chance we can have the ACSM file ready by the time the client makes that second request asking for it.
And if fulfilling a loan is slow, or broken, we can pass the current status to the patron immediately, without the risk of timeouts or long delays.