1: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
7: Setup instructions for compiling and running Bookie:
8: <p>If you're just browsing or don't need to edit files directly, you can
9: look at Bookie through the <a
10: href="http://www.mozdev.org/source/browse/bookie/">web interface</a>. </p>
11: <p>If you want to contribute to Bookie or compile it, then you should grab
12: a CVS <a href="http://www.cvshome.com">client</a> and set up a workspace
13: for bookie.</p>
14: <p>You download bookie by doing this (you only need to login once, the password
15: is guest). Please use the prune option when checking out and updating, since
16: the CVS tree has a lot of dead branches in it.</p>
17: <pre> cvs -d :pserver:email@example.com:/cvs login<br> cvs -d :pserver:firstname.lastname@example.org:/cvs co bookie -P<br></pre>
18: <p>The java client is in <code>/clients/swing</code>. There is an<a
19: href="http://jakarta.apache.org/ant">ant</a> script that should compile everything.
20: The client depends on Jena, Apache XML-RPC, Log4J and Xerces. All the libraries
21: should be available in lib. The client's main class is<code>com.tersesystems.bookie.client.Client</code>.
22: Downloading<a href="http://tersesystems.com/bookie/client.jar">client.jar</a>
23: will give you the classes, source code and javadoc to play with.</p>
24: <p>The java server is in <code>/server</code>. Again, the<a
25: href="http://jakarta.apache.org/ant">ant</a> script that should compile everything.
26: The server currently depends on JTidy, Marquee XML-RPC, Jisp, Servlet 2.2,
27: Log4J, and Xerces, which are all available in lib. The server's main class
28: is <code>com.tersesystems.bookie.service.xmlrpc.BookieServlet</code>.</p>
29: <p> The server will create four files on initialization in the current directory:
32: <li>profile.db - a database of profile information.</li>
33: <li>profile.idx - an index of profile.db</li>
34: <li>bookmarks.db - a database of bookmarks information.</li>
35: <li>bookmarks.idx - an index of bookmarks.db</li>
38: These databases contain all the information needed for the server to work.
39: Deleting these files will cause the server to start off fresh.
40: <p> The server does not attempt to limit multiple logins on the same account
41: from different servers. However, care should be taken with this feature,
42: as there is no facility to distribute messages between clients that a
43: branch has been deleted. </p>
44: <p> Bookmarks are cached on the server, but since bookmarks are unique to
45: each client this isn't that much of a win. Performance seems okay for
46: now (and if anything seems bound on the XML processing and IO overhead).
47: Database operations are not transactional.</p>
48: <p> The server uses an MD5 hashed password for authentication of the client.
49: Once authenticated, the server maintains a session based off the IP address
50: of the client. All data is sent in the clear, and as such the passwords
51: and XML-RPC information may be <a
52: href="http://www.robertgraham.com/pubs/sniffing-faq.html">packet sniffed</a>.
53: Even if the attacker does not know the clear-text password, he can still
54: send the MD5 hash to be authenticated as the user. Unfortunately, XML-RPC
55: does not cover <a
56: href="http://www.strongsec.com/tutorials/security.htm">security</a> and
57: session management very well; if there are any new RFCs I would love to
58: hear about them. One possible RFC is <a
59: href="http://jimfl.tensegrity.net">Jim Flanagan's</a> <a
60: href="http://jimfl.tensegrity.net/xmlrpc/">proposal</a>, but this requires
61: the use of <a href="http://www.ietf.org/rfc/rfc2617.txt">HTTP digest
62: authentication</a>, which I believe most clients don't support.</p>