--- bookie/www/setup.html 2001/01/20 23:36:00 1.2 +++ bookie/www/setup.html 2003/02/08 21:18:05 1.13 @@ -1,57 +1,66 @@ - -Setup instructions for 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. - -

- cvs -d :pserver:guest@mozdev.org:/cvs login
- cvs -d :pserver:guest@mozdev.org:/cvs co bookie
- -After doing this, you'll see files in the workspace. The Java server will -compile, but I use a custom made tool which pretty much no-one else uses, so -you may want to try putting it together with ANT. -

-The Java server talks to a database on the backend. I use Solid, but any JDBC compliant driver -should work (I don't use any complicated SQL). You can edit the JDBC -driver: it's defined in bookie.properties in the scripts directory. -

-The database DDL scripts are in the /sql/solid directory. They work fine -for me... again, if you're using another database, you probably want to -tweak these. Any additions are welcomed. -

-The database needs data in order to work. I wrote /scripts/import.pl which -takes in my bookmarks.html file from Netscape and pumps it into the -database. It actually relies on a couple of none standard modules which you -may need to download from ActivePerl or CPAN. -

- -After you've started the database, and compiled the Java, you probably want -to add a couple of things to your classpath. In the /lib directory, I've -added some JAR files which are needed by Bookie to work. After adding those -files (and the JDBC driver, if it's not already included), you can start the -server by using /scripts/server.bat. - -

-There is a very simple client available which I have been using for -debugging. You can run the client by using /scripts/client.bat. It's good -enough to send text to the server and get a response back, which is all I -really need from it. I'm divided as to how much time I should spend on, -since working on the client would take time away from working on the Mozilla -integration. - -

-The mozilla integration is in a sorry state. The basic problem is that I -don't understand Javascript, and I only have a hazy idea of the way that -Mozilla organizes their network code. As a result, I've spent much time -flailing around trying to get some very simple things trying to work. -Again, any assistance is appreciated. - -

-If these directions are unclear or confusing, please e-mail me at will_sargent@yahoo.com \ No newline at end of file + + + + + + +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.

+ +