OSBW Technical Design

Revision as of 13:15, 6 February 2009 by Ch (Talk | contribs) (Availability in Local Libraries)

Revision as of 13:15, 6 February 2009 by Ch (Talk | contribs) (Availability in Local Libraries)

OSBW Main Page

If you are a technical sort, interested in discussing technical issues, this is the place to do it.

Availability in Local Libraries

OpenBook currently provides a link to the WorldCat record as a way of showing availability in libraries. Thing is, WorldCat only shows availability for member libraries. I think it is possible to do more. If a library has a web-based catalogue, the catalogue is usually designed to be findable and it works in a consistent way. Usually it is a simple search box and button, defaulting to a keyword search, with results wrapped in hyperlink. Again, it is designed to be findable and consistent. Why not take advantage of that and use a little screen-scraping to see if a result exists for a given title? No doubt there are variations between catalogues, but how many library catalogues exist? And surely, a few simple rules per type could make things work.The user will be invited to configure their library using "the fuzzy library adaptor", a wizard that tests the catalogue. If the test fails, WorldCat can still be used. This feature is my current main interest. --Johnmiedema 06:30, 12 January 2009 (PST)

Existing solutions & examples

There's a web service called SeeAlso[1] that could be useful for availability check.

More information:

Sharing Code Modules

Why reinvent the wheel? My next steps with OpenBook will work toward separating the WordPress code from the generic code. This will begin to create PHP modules available for reuse by others. Are you doing the same?

One question: I'm writing in PHP. How about others? --Johnmiedema 06:30, 12 January 2009 (PST)

  • PHP mainly (interested in Python, but no real experience) --tomkeays 08:48, 12 January 2009 (PST)

Live vs. Cached Design

Currently OpenBook connects to Open Library via a live connection. If Open Library is down, OpenBook uses exception handling to prevent a hang. I have been thinking about the option of a cached design in which a widget can choose to download a cover image locally, and use static HTML for the rest. Once the HTML is written, the page would not ever have to call the datasource again. Thoughts? --Johnmiedema 06:30, 12 January 2009 (PST)

Cached

Pro

  • Data still available when a service is down
  • Less traffic for data providers
  • Less traffic for users of book widgets (blogs, etc.)
  • False data is not easily corrected

Live

Pro

  • Much more easy to integrate data in a website
  • No need for a database
  • Always fresh data. Corrections in data source are shown instantly

Service Based Design

This is just an idea that has been kicking around in my head. There are advantages to having a service based design. Right now, the heavy coding has to be done in WordPress, Drupal, Firefox, etc. How about a widget server that does all the work, returning the HTML. The only work that would have to be done on the client side is the call to the server. Dependence on a central server has its downsides too, e.g., downtime, but it could play an important role in the "book widget ecology". I have been thinking about designing OpenBook with a separate "server" module that encapsulates the functions I would hope to find on a server someday. --Johnmiedema 06:31, 12 January 2009 (PST)