Setup instructions for compiling and running Bookie:

If you're just browsing or don't need to edit files directly, you can look at Bookie through the web interface.

If you want to contribute to Bookie or compile it, then you should grab a CVS client and set up a workspace for bookie.

You download bookie by doing this (you only need to login once, the password is guest). Please use the prune option when checking out and updating, since the CVS tree has a lot of dead branches in it.

cvs -d :pserver:guest@mozdev.org:/cvs login
cvs -d :pserver:guest@mozdev.org:/cvs co bookie

The java client is in /clients/swing. There is anant script that should compile everything. The client depends on Jena, Apache XML-RPC, Log4J and Xerces. All the libraries should be available in lib. The client's main class iscom.tersesystems.bookie.client.Client. Downloadingclient.jar will give you the classes, source code and javadoc to play with.

The java server is in /server. Again, theant script that should compile everything. The server currently depends on JTidy, Marquee XML-RPC, Jisp, Servlet 2.2, Log4J, and Xerces, which are all available in lib. The server's main class is com.tersesystems.bookie.service.xmlrpc.BookieServlet.

The server will create four files on initialization in the current directory:

These databases contain all the information needed for the server to work. Deleting these files will cause the server to start off fresh.

The server does not attempt to limit multiple logins on the same account from different servers. However, care should be taken with this feature, as there is no facility to distribute messages between clients that a branch has been deleted.

Bookmarks are cached on the server, but since bookmarks are unique to each client this isn't that much of a win. Performance seems okay for now (and if anything seems bound on the XML processing and IO overhead). Database operations are not transactional.

The server uses an MD5 hashed password for authentication of the client. Once authenticated, the server maintains a session based off the IP address of the client. All data is sent in the clear, and as such the passwords and XML-RPC information may be packet sniffed. Even if the attacker does not know the clear-text password, he can still send the MD5 hash to be authenticated as the user. Unfortunately, XML-RPC does not cover security and session management very well; if there are any new RFCs I would love to hear about them. One possible RFC is Jim Flanagan's proposal, but this requires the use of HTTP digest authentication, which I believe most clients don't support.