The Book package provides an interface to a real store of data. Different sources of data interact with the rest of the code via a `Book` interface. An implementation of `Book` is expected to be able to retrieve Biblical text for a given `Passage`, and to return a `Passage` of verses that contain a word.

A Bible is a specialization of a Book that uses Passages as basic data types.

The folowing is out of date since the Version -> Book/Bible split

There are several specializations of the `Book` interface. A `MutableBook` is-a `Book` that can be changed either to accomodate Verse based notes or for a normal `Book` that can be created at run-time. The latter option allows this system to be installed on a computer that already has OLB installed without requiring a download of the complete Bible source, but the source is created either as part of the install or on the fly, and cached here.

Secondly a `Translation` is a `Book` that understands Strongs numbering and can give information about how words are translated to and from the original.

Currently there are 2 basic implementations of the `Book` interface - an `ODBCBook` and a `FileBook`. The former acts on an Access database via JBDC and ODBC. The latter on an experimental serialized data store. Probably neither of these implementations are of any long term use, however they do help get me up to speed quickly.

I invisage at least 2 more production stores - an `OLBBook` that reads directly from OLB files exactly as installed on Windows. (Maybe in reality there needs to be an `OLB7Book` and an `OLB8Book` or something) and a `RemoteBook` that uses RMI / CORBA / HTTP or whatever to retrieve the data from a remote server)

It is important that multiple data sources are available, to allow a compact download time. In an ideal world the base download, would be small enough to place as an applet on a web page, with some kind of "Save as application functionality" that still uses a remote data server. A cacheing Book could then store verses locally, only using the network for verses not retrieved yet.

The Biblical text is returned to the application as an XML document. Allowing `Book`s to contain data like red-letter markup that a display module may not want to use. See the display section for more details.

More work is needed here to with Strongs numbers and non-Biblical text sources. (Lexicons and such like)

### Startup

The startup procedure goes like this. When `Books` is first called it looks up the implementations of BookDriver (using Project.resource()) and calls registerDriver() for each. This calls getBooks() on the new BookDriver which should return an array of BookMetaData objects.

Ideally when the BookDriver creates a BookMetaData object it should also create a Book to go with it, and do everything it can to ensure that future reads from the Book will be Exception free, but without consuming significant system resources. So the process of constructing a BookMetaData and associated Book should check that the index file exists and is readable, but not actually load it. BookDriver is allowed to complain that it can't do everything it wants, but it should not hand BookMetaData objects back that are faulty.

This means that the user can browse through the BookMetaData objects without causing any stress to the system, and yet be fairly assured that when they do call getBook() on the BookMetaData that everything will work fine.

Finally when BookMetaData.getBook() is called, it should ask the Book to load any system resources that are needed to fulfil the requests.

### Cacheing

We used to have a CacheingBookDriver (now deleted) that was designed to allow data to be cached as it is read. Maybe at some stage we should add it back in again, but we would need to make Drivers writable before we do that.

The designed features of CacheingBookDriver are:

- Ability to cache multiple (possibly remote) sources
- Use of JDBC style URL to help cached data to re-connect with source
- Can be used with multiple cacheing schemes (sword, ser, ...)

So it is up to the actual cacheing scheme to distinguish cached data from other normal data, and to be able to return a original source URL in case not all of the data is present.