[Booki-dev] booki

[Douglas Bagnall]

hi Duke

> I think it would be great to see a data structure model of what the
> internals of Booki look like now and/or what the spec for git
> integration will be. Is there anything like that currently?


Not really.  I can't say much about the internals of Booki, but the
proposal for git integration goes like this:

 * Every book is a branch of the same repo, for easy forking and
   merging ('remixing' in FM terms).

 * Each file save is a commit (though adding/changing an image might
   put both the html and the image file in the same commit).

 * Reading will generally not check out a working tree, rather work
   from the bare repository, ala gitweb.

 * Writing will not require a full working tree either, though it
   might use an empty temporary working directory in which it will
   write the changed file, because that is simpler to start with than
   pushing the blob directly to the git index.

 * Low level locking seems to be taken care of by git's design (e.g.
   http://www.gelato.unsw.edu.au/archives/git/0609/28045.html), so
   races can safely be dealt with by, say, retrying until the commits
   settle into one order or another.

There is a lot that I've forgotten while I've been working on epub
import/export, but it will probably come back and I might even find
notes.

Each book has all its html in its root directory, and all its images
and other attachments in a directory called 'static'.  This is of
course for the convenience of the web server: the html can undergo
munging while the static stuff is served directly.

To communicate with Objavi and Espri, the export and import scripts,
Booki uses the 'booki-zip' format which is just a zip file containing
the book's tree along with a file called 'info.json' that contains the
ToC and metadata.  There are several examples at
http://objavi.flossmanuals.net/booki-books/, but be warned that the
info.json format is undergoing revision.  I'll write about that soon.


Douglas