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 login
 cvs -d co bookie -P

The java client is in /clients/swing. There is an ant 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 is com.tersesystems.bookie.client.Client. Downloading client.jar will give you the classes, source code and javadoc to play with.

The java server is in /server. Again, the ant 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 also starts up with a large amount of debugging information. You can override the default configuration by specifying the log4j configuration file on the command line with -Dlog4j.configuration=minimal.txt where the file minimal.txt contains the following:

    # Set root logger level to INFO and its only appender to A1.
    log4j.rootLogger=INFO, A1
    # A1 is set to be a ConsoleAppender. 
    # A1 uses PatternLayout.
    log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

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.