X-Git-Url: http://www.project-moonshot.org/gitweb/?a=blobdiff_plain;f=lib%2FHACKING;h=36287b8f9100359b03de8dc5b50e9f4e85867025;hb=e1fe1879285c0a74ae3e906f45b3da326144fd0d;hp=8163fdfe54862d51ceaab8afbc1bdc1f9e398546;hpb=5886bda12130ff8e76c4dd73762c183c1ab31871;p=radsecproxy.git

diff --git a/lib/HACKING b/lib/HACKING
index 8163fdf..36287b8 100644
--- a/lib/HACKING
+++ b/lib/HACKING
@@ -1,44 +1,69 @@
 HACKING file for libradsec (in Emacs -*- org -*- mode).
 
-Status as of libradsec-0.0.1 (2010-10-05).
+Status as of libradsec-0.0.2.dev (2011-03-24).
 
 * Build instructions
 cd libradsec/lib
-ln -s /usr/share/libtool/config/ltmain.sh ..	# bug
 sh autogen.sh
-./configure 	# bug -- won't complain when missing libraries
+./configure #--enable-tls
 make
-examples/client examples/client.conf blocking ; echo $?
+
+examples/client -r examples/client.conf blocking-tls; echo $?
 
 * Design of the API
-- There are three usage models.
-  - You use the send and receive calls in blocking mode.
-  - You run the libevent loop and get callbacks instead of doing
-    blocking reads.
-  - You run your own event loop, using fd's for select and do the i/o
-    using the libradsec send/receive calls.
-- Fully reentrant (FIXME: any issues with libfreeradius-radius?)
+- There are three usage modes
+  - Application use the send and receive calls (blocking mode)
+  - Application registers callbacks and runs the libevent dispatch
+    loop (a.k.a. user dispatch mode)
+  - Application runs its own event loop, using fd's for select and
+    performs I/O using the libradsec send/receive calls
+    (a.k.a. on-your-own mode)
+- User chooses allocation regime
 
+Note that as of 0.0.2.dev libradsec suffers from way too much focus on
+the behaviour of a blocking client and is totally useless as a server.
+Not only does it lack most of the functions needed for writing a
+server but it also contains at least one architectural mishap which
+kills the server idea -- a connection timeout (TCP) or a retransmit
+timeout (UDP) will result in the event loop being broken.  The same
+thing will happen if there's an error on a TCP connection, f.ex. a
+failing certificate validation (TLS).
 * Dependencies
-- libfreeradius-radius -- no i/o used
-- libconfuse
-- libevent 2.0.x -- not packaged yet!
+Details apply to Ubuntu 10.10.
 
+- libconfuse (2.7-1)
+  sudo apt-get install libconfuse-dev libconfuse0
+- libevent from source (release-2.0.10-stable)
+  git clone --branch release-2.0.10-stable git://levent.git.sourceforge.net/gitroot/levent/levent
+  cd levent; sh autogen.sh && ./configure --enable-openssl
+  make && sudo make install
+- OpenSSL (optional, for TLS and DTLS support)
+  sudo apt-get install libssl-dev
+  
 * Functionality and quality
-** Tested and verified
 ** Not well tested
 - reading config file
-- short read
-- short write
-- autoconf/automake/libtool
+- [TCP] short read
+- [TCP] short write
+- [TLS] basic tls support
+- [TLS] preshared key support
+- [TLS] verification of CN
 ** Known issues
-- leaking memory
-- udp issues with libevent
+- error stack is only one entry deep
+- custom allocation scheme is not used in all places
 ** Not implemented
-- client: matching responses, resending packets
-- custom allocation scheme used in all places
-- callbacks invoked properly
 - server failover
-- TLS support
-- TLS preshared key support
-- DTLS support
+- [DTLS] support
+
+* Found a bug?
+Please report it.  This is how we improve the quality of the code.
+
+If possible, please build the library with DEBUG defined (CFLAGS="-g
+-DDEBUG") and reproduce the problem.  With DEBUG defined, lots of
+asserts are enabled which might give a hint about what's gone wrong.
+
+Running the library under gdb is another good idea.  If you experience
+a crash, catching it in gdb and providing a backtrace is highly
+valuable for debugging.
+
+Contact: mailto:linus+libradsec@nordu.net