Diff for /bookie/www/setup.html between versions 1.2 and 1.11

version 1.2, 2001/01/20 23:36:00 version 1.11, 2002/07/06 00:44:21
Line 1 Line 1
   Setup instructions for compiling and running Bookie:
 Setup instructions for Bookie.  
 <p>  <p>
 If you're just browsing or don't need to edit files directly, you can look  If you're just browsing or don't need to edit files directly, you can look
 at Bookie through the <a  at Bookie through the <a
 href="http://www.mozdev.org/source/browse/bookie/">web interface</a>.  href="http://www.mozdev.org/source/browse/bookie/">web interface</a>.
 <p>  <p>
 If you want to contribute to Bookie or compile it, then you should grab a  If you want to contribute to Bookie or compile it, then you should grab a
CVS <a href="www.cvshome.com">client</a> and set up a workspace for bookie.CVS <a href="http://www.cvshome.com">client</a> 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.
 <pre>  <pre>
  cvs -d :pserver:guest@mozdev.org:/cvs login   cvs -d :pserver:guest@mozdev.org:/cvs login
 cvs -d :pserver:guest@mozdev.org:/cvs co bookie cvs -d :pserver:guest@mozdev.org:/cvs co bookie -P
 </pre>  </pre>
 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 <a  
 href="http://www.solidtech.com">Solid</a>, 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.  
 <p>  <p>
There is a very simple client available which I have been using forThe java client is in <code>/clients/swing</code>.  There is an
debugging.  You can run the client by using /scripts/client.bat.  It's good<a href="http://jakarta.apache.org/ant">ant</a> script that should compile
enough to send text to the server and get a response back, which is all Ieverything.  The client depends on Jena, Apache XML-RPC, Log4J and Xerces.
really need from it.  I'm divided as to how much time I should spend on,All the libraries should be available in lib.  The client's main class is
since working on the client would take time away from working on the Mozilla<code>com.tersesystems.bookie.client.Client</code>.  Downloading
integration.<a href="http://tersesystems.com/bookie/client.jar">client.jar</a> will give you
 the classes, source code and javadoc to play with.
 The java server is in <code>/server</code>.  Again, the
 <a href="http://jakarta.apache.org/ant">ant</a> 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 <code>com.tersesystems.bookie.service.xmlrpc.BookieServlet</code>.
   The server will create four files on initialization in the current directory:
     <li>profile.db - a database of profile information.</li>
     <li>profile.idx - an index of profile.db</li>
     <li>bookmarks.db - a database of bookmarks information.</li>
     <li>bookmarks.idx - an index of bookmarks.db</li>
   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 <code>-Dlog4j.configuration=minimal.txt</code> where the 
   file <code>minimal.txt</code> contains the following:
The mozilla integration is in a sorry state.  The basic problem is that I    # Set root logger level to INFO and its only appender to A1.
don't understand Javascript, and I only have a hazy idea of the way that    log4j.rootLogger=INFO, A1
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.    # A1 is set to be a ConsoleAppender. 
Again, any assistance is appreciated.    log4j.appender.A1=org.apache.log4j.ConsoleAppender
     # A1 uses PatternLayout.
     log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
 <p>  <p>
 If these directions are unclear or confusing, please e-mail me at <a href="mailto:will_sargent@yahoo.com">will_sargent@yahoo.com</a>  
     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 
     <a href="http://www.robertgraham.com/pubs/sniffing-faq.html">packet sniffed</a>. 
     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 
     <a href="http://www.strongsec.com/tutorials/security.htm">security</a> and session management
     very well; if there are any new RFCs I would love to hear about them.  One
     possible RFC is <a href="http://jimfl.tensegrity.net">Jim Flanagan's</a> 
     <a href="http://jimfl.tensegrity.net/xmlrpc/">proposal</a>, but this requires
     the use of <a href="http://www.ietf.org/rfc/rfc2617.txt">HTTP digest 
     authentication</a>, which I believe most clients don't

Removed from v.1.2  
changed lines
  Added in v.1.11

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>