When patrons have problems borrowing and reading books, the problem could be in one of a number of places:

1. The patron's individual mobile device
2. The version of the SimplyE client the patron is using
3. The library registry, which manages the patron's Adobe Client ID
4. The circulation manager the patron is connecting to
5. The ILS the patron is authenticating with
6. The distributor that's managing the loan and providing the book

This makes it very difficult to isolate problems.

When a new distributor is writing an OPDS server (as Internet Archive is now), we have an even wider variety of difficult-to-debug problems.

A simple OPDS client written in Python could validate OPDS servers – either custom ones or circulation managers – from the outside. It should be able to identify, if not diagnose, all problems in the 3-6 range.

This client would need knowledge of a number of protocols – probably these at least:

• OPDS 1.2
• OPDS For Library Patrons
• Authentication For OPDS
• NYPL's extensions to A4OPDS
• The Short Client Token validation technique and the custom Adobe API implemented by the library registry to turn tokens into Adobe Client IDs.

We could also give it knowledge of the specific quirks of the SimplyE mobile clients, though these would need to be adjusted over time.

To run this client you would provide an OPDS endpoint and some credentials. The client would validate the credentials, find the patron's current loans, validate its Short Client Token, and try to borrow and fulfill books. It would summarize its actions if successful, and if there were any obvious problems it would report the problems. If a server did things that were legal OPDS but that SimplyE is currently unable to handle, it could notice these things and complain.