28 files changed, 374 insertions, 95 deletions

diff --git a/src/array.h b/src/array.h
index 43892ee..75c5dd3 100644
--- a/src/array.h
+++ b/src/array.h
@@ -13,6 +13,7 @@ namespace Bu
          *@param value (typename) The type of data to store in your list
          *@param valuealloc (typename) Memory Allocator for your value type
          *@param linkalloc (typename) Memory Allocator for the list links.
+         *@ingroup Containers
          */
         template<typename value, int inc=10, typename valuealloc=std::allocator<value> >
         class Array
diff --git a/src/atom.h b/src/atom.h
index e950a96..1786cf3 100644
--- a/src/atom.h
+++ b/src/atom.h
@@ -9,6 +9,7 @@ namespace Bu
 {
         /**
          *
+         *@ingroup Containers
          */
         template <typename t, typename talloc=std::allocator<t> >
         class Atom
diff --git a/src/client.h b/src/client.h
index 2b7448c..4188a49 100644
--- a/src/client.h
+++ b/src/client.h
@@ -11,7 +11,8 @@ namespace Bu
         class Socket;
 
         /**
-         *
+         *@author Mike Buland
+         *@ingroup Serving
          */
         class Client
         {
diff --git a/src/doxy/archives.dox b/src/doxy/archives.dox
new file mode 100644
index 0000000..3b96aa3
--- /dev/null
+++ b/src/doxy/archives.dox
@@ -0,0 +1,9 @@
+/**
+ *@page howto_archives Archiving Your Data a.k.a. Serialization
+ *
+ * Archives are a simple system for providing basic-level data-structure
+ * serialization in a fast and simple manner.  They even provide a few more
+ * advanced capabilities for when you need them.
+ *
+ *@todo Finish this page.
+ */
diff --git a/src/doxy/groups.dox b/src/doxy/groups.dox
new file mode 100644
index 0000000..7bff7a7
--- /dev/null
+++ b/src/doxy/groups.dox
@@ -0,0 +1,19 @@
+/**
+ *@defgroup Threading
+ * Threads are awesome.
+ */
+
+/**
+ *@defgroup Serving
+ * Serving data is pretty cool too.
+ */
+
+/**
+ *@defgroup Containers
+ * Containers for data.
+ */
+
+/**
+ *@defgroup Taf
+ * Taf is the best!
+ */
diff --git a/src/main.dox b/src/doxy/main.dox
index 668d2e3..7268890 100644
--- a/src/main.dox
+++ b/src/doxy/main.dox
@@ -7,6 +7,13 @@
  * cover a wide range of topics from streams and sockets to data structures to
  * data serialization and xml handling to threading.
  *
+ * This documentation is expanding all the time, and should contain
+ * comprehensive guides and API reference, but doesn't yet.  For now check out
+ * these sections:
+ * - @ref howto_streams
+ * - @ref howto_archives
+ * - @ref howto_threading
+ * - @ref howto_servers
  */
 
 /**
diff --git a/src/doxy/servers.dox b/src/doxy/servers.dox
new file mode 100644
index 0000000..0ba4bb1
--- /dev/null
+++ b/src/doxy/servers.dox
@@ -0,0 +1,11 @@
+/**
+ *@page howto_servers Creating Internet Servers
+ *
+ * Libbu++ provides a comprehensive set of classes for creating any type of
+ * server that you would like.  At the moment these are restricted to using
+ * the Bu::Socket subclass of Bu::Stream, and therefore the INET socket
+ * namespace.  This isn't much of a restriction, but hopefully it will be
+ * lifted in the future.
+ *
+ *@todo Finish this page.
+ */
diff --git a/src/doxy/streams.dox b/src/doxy/streams.dox
new file mode 100644
index 0000000..65f01d7
--- /dev/null
+++ b/src/doxy/streams.dox
@@ -0,0 +1,158 @@
+/**
+ *@page howto_streams Working With Streams
+ *
+ * Working with libbu++ streams is simple and very straight-forward, but there
+ * are a few things to understand when you pick them up for the first time.
+ *
+ *@section whatis What is a stream?
+ * A stream is a mechanism that allows data to be transported from one place to
+ * another without interruption and in order.  Examples of this include data
+ * being written to a file or being read from a file, data being written to a
+ * network socket or read from a network socket, and so on.
+ * Every type of stream will support a different number of options, for example
+ * file streams are usually seekable, that is, you can select where in the file
+ * you are reading and writing, however network sockets are not seekable.  All
+ * of these properties can be determined at runtime through the Stream class.
+ *
+ *@section filters Using filters with streams
+ * Libbu++ supports a special type of Stream that is known as a Filter.  Filters
+ * are actually streams, except instead of reading or writing to or from a
+ * file they read or write to or from another stream.  This provides a handy
+ * way of chaining any number of filters together along with end-point streams
+ * such as files.  One example of this would be applying a BZip2 compression
+ * filter to a file stream to compress all data being written to it.
+ * Once a filter is applied the transformations that it applies to the data will
+ * happen automatically as you use the stream.
+ *
+ * One important thing to remember about streams is that they will commonly
+ * change the options that you have when it comes to interacting with the
+ * stream.  This is not a bad thing, it is necesarry, but it is easy to tell
+ * when this is happening.  To continue with the above example, you can seek in
+ * a File stream, but not in a BZip2 filtered File stream.  This has to do with
+ * the way the compression algorithms work and restrict the operations that can
+ * be easily performed on the data.
+ *
+ * Not all changes that filters apply will be restrictive, filters such as the
+ * Buffer filter will add the ability to seek (to an extent) within the buffered
+ * data.
+ *
+ *@section difference How are libbu++ streams different form stl streams?
+ * While not globally true, many stl streams are designed for formatting the
+ * data that flows through the stream, that means that when you attempt to
+ * write a uint32_t into a standard stream it can be difficult to predict what
+ * the result will be, will it be the binary representation or a textual
+ * conversion?
+ *
+ * Libbu++ streams are very direct about how the data is handled.  All end-point
+ * streams will always handle the data that you provide or request without any
+ * modification or formatting, very much like the way libc style file access
+ * works.
+ *
+ * The design of Libbu++ streams was, from the begining, to try to make it as
+ * easy as possible to write general code that was as easy as possible to
+ * extend, and as clear as possible.  We have accomplished this by making
+ * streams simple, yet flexible, with a clear API and a flexible filter system
+ * that something geared towards more general formatting, conversion, and
+ * operator-only access can't touch.
+ *
+ *@section usage Using streams directly
+ * To create a stream depends on the type of stream that you're interested in,
+ * each type has it's own constructors designed to create the stream and get
+ * it ready for use.  We'll use the Bu::File stream as an example here.
+ *
+ *@code
+        // The constructor and each function call to access the stream could throw
+        // an exception, it's important to catch these and handle them
+        // appropriately.
+        try
+        {
+                // sFileName is a Bu::FString object containing the name of the file to
+                // open, possibly with path elements.  The second parameter works like
+                // the fopen mode parameter, and can be "w" for write, "r" for read, or
+                // "a" for append.  This will likely be replaced with a bitfield later.
+                Bu::File f( sFileName, "w");
+
+                // At this point we know our file is open, lets write some data to it
+                // The first parameter is a pointer to the data to write, the second is
+                // how many bytes to write.
+                f.write( "Test data, boring old test data.\n", 33 );
+
+                // We don't actually need to close the file explicitly, the
+                // deconstructor will take care of that for us, we could if we wanted
+                // to, simply by calling the f.close() function, but it isn't necesarry.
+        }
+        catch( Bu::FileException &e )
+        {
+                // Here we can report the error to the system, whatever it happened to
+                // be.
+                printf("Error:  %s\n", e.what() );
+        }
+ @endcode
+ * This is a most basic example, but it covers all the basics.  You don't need
+ * much more than this to write just about any file i/o program, just use the
+ * Bu::Stream::read() and Bu::Stream::write() functions.
+ *
+ * Now lets look at how to add a stream to the mix, we'll BZip2 compress the
+ * above example.
+ *@code
+        // Again, we want to catch exceptions in the entire file handling block.
+        try
+        {
+                // We create the file just like before, nothing different about this.
+                Bu::File f( sFileName, "w");
+
+                // Here, however, we create our Bu::BZip2 object, and pass it a
+                // reference to the file.  Now our data will go through Bu::BZip2, then
+                // into Bu::File and onto disk.  Notice that you don't have to specify
+                // wether you want to read or write explicitly, the filter can usually
+                // determine this for itself by examining the underlying stream.
+                Bu::BZip2 bz2( f );
+
+                // This is done exactly as before, but this time we write into bz2, not
+                // f.  We already know how to do this, because both BZip2 and File
+                // inherit from Bu::Stream, so they both have very similar (if not
+                // identicle) API.
+                bz2.write( "Test data, boring old test data.\n", 33 );
+
+                // Just like last time, we don't have to close either stream explicitly,
+                // they will be destroyed appropriately by the system, and in the
+                // correct order (bz2 first, then f).
+        }
+        catch( Bu::FileException &e )
+        {
+                // Here we can report the error to the system, whatever it happened to
+                // be.
+                printf("Error:  %s\n", e.what() );
+        }
+ @endcode
+ * 
+ * As you can tell in this example, using streams and filters is very easy to
+ * do, and even makes formerly very complex procedures take almost no time at
+ * all.
+ *
+ *@section usingmore Accepting strings in other classes and functions
+ *
+ * When writing a class or function that uses an already opened stream to read
+ * or write data from or to it's important to plan ahead, and probably accept
+ * an object reference of type Bu::Stream.  This makes your code immediately
+ * much more portable, useful, and flexible.  You don't have to change anything
+ * about the way you write your class or function, use the standard Bu::Stream
+ * functions like read and write just like before.
+ *
+ * For example, lets say you're creating a new image format, and need to be able
+ * to store images on disk and read them off again, so you write the approprate
+ * file fromat handlers.  By using Bu::Stream instead of Bu::File you allow
+ * anyone using your image format to send that data anywhere they would like,
+ * including files, sockets, memory buffers, composite archives, and even
+ * through types of streams that don't exist yet.  Not only that, but since
+ * every filter is a stream, anyone is now free to pass you a BZip2 filter or
+ * an encryption filter, or any other chain, so that your data can be
+ * compressed, and possibly encrypted, and sent over the network without any
+ * changes to your original code.
+ *
+ * Understandably you probably want to be sure of a few basics before you go
+ * writing image data to any old stream, such as ensuring the stream supports
+ * writing to begin with.  This can be easily handled by taking advantage of
+ * the capability accessors in Bu::Stream, these begin with "can" and "is," see
+ * the documentation for more information.
+ */
diff --git a/src/doxy/threading.dox b/src/doxy/threading.dox
new file mode 100644
index 0000000..0ae5325
--- /dev/null
+++ b/src/doxy/threading.dox
@@ -0,0 +1,15 @@
+/**
+ *@page howto_threading Making Applications Multi-threaded
+ *
+ * Libbu++ provides support for object oriented threading including full support
+ * for inter-thread communication and safety devices such as mutexes,
+ * conditions, and semaphores.  It even provides some of the basic foundation
+ * classes in thread-safe versions that often add extra functionality and make
+ * writing thread-safe programs as easy as could be.
+ *
+ * Threads in libbu++ are currently based on the posix model, but will hopefully
+ * adopt other methods behind the scenes for compatability with other operating
+ * systems.
+ *
+ *@todo Finish this page.
+ */
diff --git a/src/hash.h b/src/hash.h
index 4f508b2..62b19c9 100644
--- a/src/hash.h
+++ b/src/hash.h
@@ -165,6 +165,7 @@ namespace Bu
          *@param keyalloc (typename) Memory allocator for hashtable keys
          *@param valuealloc (typename) Memory allocator for hashtable values
          *@param challoc (typename) Byte allocator for bitflags
+         *@ingroup Containers
          */
         template<typename key, typename value, typename sizecalc, typename keyalloc, typename valuealloc, typename challoc >
         class Hash
diff --git a/src/ito.h b/src/ito.h
index c062052..4ed2c8b 100644
--- a/src/ito.h
+++ b/src/ito.h
@@ -6,11 +6,12 @@
 namespace Bu
 {
         /**
-         * Simple thread class.  This wraps the basic pthread (posix threads) system in
-         * an object oriented sort of way.  It allows you to create a class with
-         * standard member variables and callable functions that can be run in it's own
-         * thread, one per class instance.
+         * Simple thread class.  This wraps the basic pthread (posix threads)
+         * system in an object oriented sort of way.  It allows you to create a
+         * class with standard member variables and callable functions that can be
+         * run in it's own thread, one per class instance.
          *@author Mike Buland
+         *@ingroup Threading
          */
         class Ito
         {
@@ -27,24 +28,26 @@ namespace Bu
 
                 /**
                  * Begin thread execution.  This will call the overridden run function,
-                 * which will simply execute in it's own thread until the function exits,
-                 * the thread is killed, or the thread is cancelled (optionally).  The
-                 * thread started in this manner has access to all of it's class variables,
-                 * but be sure to protect possible multiple-access with ItoMutex objects.
-                 *@returns True if starting the thread was successful.  False if something
-                 * went wrong and the thread has not started.
+                 * which will simply execute in it's own thread until the function
+                 * exits, the thread is killed, or the thread is cancelled (optionally).
+                 * The thread started in this manner has access to all of it's class
+                 * variables, but be sure to protect possible multiple-access with
+                 * ItoMutex objects.
+                 * @returns True if starting the thread was successful.  False if
+                 * something went wrong and the thread has not started.
                  */
                 bool start();
 
                 /**
-                 * Forcibly kill a thread.  This is not generally considered a good thing to
-                 * do, but in those rare cases you need it, it's invaluable.  The problem
-                 * with stopping (or killing) a thread is that it stops it the moment you
-                 * call stop, no matter what it's doing.  The object oriented approach to
-                 * this will help clean up any class variables that were used, but anything
-                 * not managed as a member variable will probably create a memory leak type
-                 * of situation.  Instead of stop, consider using cancel, which can be
-                 * handled by the running thread in a graceful manner.
+                 * Forcibly kill a thread.  This is not generally considered a good
+                 * thing to do, but in those rare cases you need it, it's invaluable.
+                 * The problem with stopping (or killing) a thread is that it stops it
+                 * the moment you call stop, no matter what it's doing.  The object
+                 * oriented approach to this will help clean up any class variables
+                 * that were used, but anything not managed as a member variable will
+                 * probably create a memory leak type of situation.  Instead of stop,
+                 * consider using cancel, which can be handled by the running thread in
+                 * a graceful manner.
                  *@returns True if the thread was stopped, false otherwise.  When this
                  * function returns the thread may not have stopped, to ensure that the
                  * thread has really stopped, call join.
@@ -52,11 +55,11 @@ namespace Bu
                 bool stop();
 
                 /**
-                 * The workhorse of the Ito class.  This is the function that will run in
-                 * the thread, when this function exits the thread dies and is cleaned up
-                 * by the system.  Make sure to read up on ItoMutex, ItoCondition, and
-                 * cancel to see how to control and protect everything you do in a safe way
-                 * within this function.
+                 * The workhorse of the Ito class.  This is the function that will run
+                 * in the thread, when this function exits the thread dies and is
+                 * cleaned up by the system.  Make sure to read up on ItoMutex,
+                 * ItoCondition, and cancel to see how to control and protect
+                 * everything you do in a safe way within this function.
                  *@returns I'm not sure right now, but this is the posix standard form.
                  */
                 virtual void *run()=0;
@@ -64,13 +67,13 @@ namespace Bu
                 /**
                  * Join the thread in action.  This function performs what is commonly
                  * called a thread join.  That is that it effectively makes the calling
-                 * thread an the Ito thread contained in the called object one in the same,
-                 * and pauses the calling thread until the called thread exits.  That is,
-                 * when called from, say, your main(), mythread.join() will not return until
-                 * the thread mythread has exited.  This is very handy at the end of
-                 * programs to ensure all of your data was cleaned up.
-                 *@returns True if the thread was joined, false if the thread couldn't be
-                 * joined, usually because it isn't running to begin with.
+                 * thread an the Ito thread contained in the called object one in the
+                 * same, and pauses the calling thread until the called thread exits.
+                 * That is, when called from, say, your main(), mythread.join() will
+                 * not return until the thread mythread has exited.  This is very handy
+                 * at the end of programs to ensure all of your data was cleaned up.
+                 *@returns True if the thread was joined, false if the thread couldn't
+                 * be joined, usually because it isn't running to begin with.
                  */
                 bool join();
 
diff --git a/src/itoatom.h b/src/itoatom.h
index 7fc9090..2f8ac41 100644
--- a/src/itoatom.h
+++ b/src/itoatom.h
@@ -9,6 +9,7 @@
 /**
  * A thread-safe wrapper class.
  *@author Mike Buland
+ *@ingroup Threading
  */
 template <class T>
 class ItoAtom
diff --git a/src/itocondition.h b/src/itocondition.h
index 1793f81..517dd5f 100644
--- a/src/itocondition.h
+++ b/src/itocondition.h
@@ -10,9 +10,9 @@ namespace Bu
         /**
          * Ito condition.  This is a fairly simple condition mechanism.  As you may
          * notice this class inherits from the ItoMutex class, this is because all
-         * conditions must be within a locked block.  The standard usage of a condition
-         * is to pause one thread, perhaps indefinately, until another thread signals
-         * that it is alright to procede.
+         * conditions must be within a locked block.  The standard usage of a
+         * condition is to pause one thread, perhaps indefinately, until another
+         * thread signals that it is alright to procede.
          * <br>
          * Standard usage for the thread that wants to wait is as follows:
          * <pre>
@@ -24,10 +24,11 @@ namespace Bu
          * ...  // Take care of what you have to.
          * cond.unlock();
          * </pre>
-         * The usage for the triggering thread is much simpler, when it needs to tell
-         * the others that it's time to grab some data it calls either signal or
-         * broadcast.  See both of those functions for the difference.
+         * The usage for the triggering thread is much simpler, when it needs to
+         * tell the others that it's time to grab some data it calls either signal
+         * or broadcast.  See both of those functions for the difference.
          *@author Mike Buland
+         *@ingroup Threading
          */
         class ItoCondition : public ItoMutex
         {
@@ -43,9 +44,9 @@ namespace Bu
                 ~ItoCondition();
 
                 /**
-                 * Wait forever, or until signalled.  This has to be called from within a
-                 * locked section, i.e. before calling this this object's lock function
-                 * should be called.
+                 * Wait forever, or until signalled.  This has to be called from within
+                 * a locked section, i.e. before calling this this object's lock
+                 * function should be called.
                  */
                 int wait();
 
@@ -60,16 +61,18 @@ namespace Bu
                 int wait( int nSec, int nUSec );
 
                 /**
-                 * Notify the next thread waiting on this condition that they can go ahead.
-                 * This only signals one thread, the next one in the condition queue, that
-                 * it is safe to procede with whatever operation was being waited on.
+                 * Notify the next thread waiting on this condition that they can go
+                 * ahead.  This only signals one thread, the next one in the condition
+                 * queue, that it is safe to procede with whatever operation was being
+                 * waited on.
                  */
                 int signal();
 
                 /**
-                 * Notify all threads waiting on this condition that they can go ahead now.
-                 * This function is slower than signal, but more effective in certain
-                 * situations where you may not know how many threads should be activated.
+                 * Notify all threads waiting on this condition that they can go ahead
+                 * now. This function is slower than signal, but more effective in
+                 * certain situations where you may not know how many threads should be
+                 * activated.
                  */
                 int broadcast();
 
diff --git a/src/itomutex.h b/src/itomutex.h
index 9c9d205..27ca125 100644
--- a/src/itomutex.h
+++ b/src/itomutex.h
@@ -7,10 +7,11 @@ namespace Bu
 {
         /**
          * Simple mutex wrapper.  Currently this doesn't do anything extra for you
-         * except keep all of the functionality together in an OO sorta' way and keep
-         * you from having to worry about cleaning up your mutexes properly, or initing
-         * them.
+         * except keep all of the functionality together in an OO sorta' way and
+         * keep you from having to worry about cleaning up your mutexes properly,
+         * or initing them.
          *@author Mike Buland
+         *@ingroup Threading
          */
         class ItoMutex
         {
@@ -23,33 +24,33 @@ namespace Bu
                 /**
                  * Destroy a mutex.  This can only be done when a mutex is unlocked.
                  * Failure to unlock before destroying a mutex object could cause it to
-                 * wait for the mutex to unlock, the odds of which are usually farily low
-                 * at deconstruction time.
+                 * wait for the mutex to unlock, the odds of which are usually farily
+                 * low at deconstruction time.
                  */
                 ~ItoMutex();
 
                 /**
-                 * Lock the mutex.  This causes all future calls to lock on this instance
-                 * of mutex to block until the first thread that called mutex unlocks it.
-                 * At that point the next thread that called lock will get a chance to go
-                 * to work.  Because of the nature of a mutex lock it is a very bad idea to
-                 * do any kind of serious or rather time consuming computation within a
-                 * locked section.  This can cause thread-deadlock and your program may
-                 * hang.
+                 * Lock the mutex.  This causes all future calls to lock on this
+                 * instance of mutex to block until the first thread that called mutex
+                 * unlocks it.  At that point the next thread that called lock will get
+                 * a chance to go to work.  Because of the nature of a mutex lock it is
+                 * a very bad idea to do any kind of serious or rather time consuming
+                 * computation within a locked section.  This can cause thread-deadlock
+                 * and your program may hang.
                  */
                 int lock();
 
                 /**
-                 * Unlock the mutex.  This allows the next thread that asked for a lock to
-                 * lock the mutex and continue with execution.
+                 * Unlock the mutex.  This allows the next thread that asked for a lock
+                 * to lock the mutex and continue with execution.
                  */
                 int unlock();
 
                 /**
-                 * Try to lock the mutex.  This is the option to go with if you cannot avoid
-                 * putting lengthy operations within a locked section.  trylock will attempt
-                 * to lock the mutex, if the mutex is already locked this function returns
-                 * immediately with an error code.
+                 * Try to lock the mutex.  This is the option to go with if you cannot
+                 * avoid putting lengthy operations within a locked section.  trylock
+                 * will attempt to lock the mutex, if the mutex is already locked this
+                 * function returns immediately with an error code.
                  */
                 int trylock();
 
diff --git a/src/itoqueue.h b/src/itoqueue.h
index 5945344..1a4e0b6 100644
--- a/src/itoqueue.h
+++ b/src/itoqueue.h
@@ -16,6 +16,7 @@ namespace Bu
          * something is enqueued within the specified time limit, or NULL if the
          * time limit is exceded.
          *@author Mike Buland
+         *@ingroup Threading Containers
          */
         template <class T>
         class ItoQueue
@@ -59,11 +60,11 @@ namespace Bu
                 }
 
                 /**
-                 * Enqueue a pieces of data.  The new data will go at the end of the queue,
-                 * and unless another piece of data is enqueued, will be the last piece of
-                 * data to be dequeued.
-                 *@param pData The data to enqueue.  If this is not a primitive data type
-                 * it's probably best to use a pointer type.
+                 * Enqueue a pieces of data.  The new data will go at the end of the
+                 * queue, and unless another piece of data is enqueued, will be the
+                 * last piece of data to be dequeued.
+                 *@param pData The data to enqueue.  If this is not a primitive data
+                 * type it's probably best to use a pointer type.
                  */
                 void enqueue( T pData )
                 {
@@ -91,20 +92,22 @@ namespace Bu
                 }
 
                 /**
-                 * Dequeue the first item from the queue.  This function can operate in two
-                 * different modes, blocking and non-blocking.  In non-blocking mode it will
-                 * return immediately weather there was data in the queue or not.  If there
-                 * was data it will remove it from the queue and return it to the caller.
-                 * In blocking mode it will block forever wating for data to be enqueued.
-                 * When data finally is enqueued this function will return immediately with
-                 * the new data.  The only way this function should ever return a null in
-                 * blocking mode is if the calling thread was cancelled.  It's probably a
-                 * good idea to check for NULL return values even if you use blocking, just
-                 * to be on the safe side.
-                 *@param bBlock Set to true to enable blocking, leave as false to work in
-                 * non-blocking mode.
-                 *@returns The next piece of data in the queue, or NULL if no data was in
-                 * the queue.
+                 * Dequeue the first item from the queue.  This function can operate in
+                 * two different modes, blocking and non-blocking.  In non-blocking
+                 * mode it will return immediately weather there was data in the queue
+                 * or not.  If there was data it will remove it from the queue and
+                 * return it to the caller.
+                 *
+                 * In blocking mode it will block forever wating for data to be
+                 * enqueued.  When data finally is enqueued this function will return
+                 * immediately with the new data.  The only way this function should
+                 * ever return a null in blocking mode is if the calling thread was
+                 * cancelled.  It's probably a good idea to check for NULL return
+                 * values even if you use blocking, just to be on the safe side.
+                 *@param bBlock Set to true to enable blocking, leave as false to work
+                 * in non-blocking mode.
+                 *@returns The next piece of data in the queue, or NULL if no data was
+                 * in the queue.
                  */
                 T dequeue( bool bBlock=false )
                 {
@@ -143,15 +146,15 @@ namespace Bu
                 }
 
                 /**
-                 * Operates just like the other dequeue function in blocking mode with one
-                 * twist.  This function will block for at most nSec seconds and nUSec
-                 * micro-seconds.  If the timer is up and no data is available, this will
-                 * just return NULL.  If data is enqueued before the timeout expires, it
-                 * will dequeue and exit immediately.
+                 * Operates just like the other dequeue function in blocking mode with
+                 * one twist.  This function will block for at most nSec seconds and
+                 * nUSec micro-seconds.  If the timer is up and no data is available,
+                 * this will just return NULL.  If data is enqueued before the timeout
+                 * expires, it will dequeue and exit immediately.
                  *@param nSec The number of seconds to wait, max.
                  *@param nUSec The number of micro-seconds to wait, max.
-                 *@returns The next piece of data in the queue, or NULL if the timeout was
-                 * exceeded.
+                 *@returns The next piece of data in the queue, or NULL if the timeout
+                 * was exceeded.
                  */
                 T dequeue( int nSec, int nUSec )
                 {
@@ -195,9 +198,9 @@ namespace Bu
                 }
 
                 /**
-                 * Checks to see if the queue has data in it or not.  Note that there is no
-                 * function to determine the length of the queue.  This data isn't kept
-                 * track of.  If you really need to know, fix this.
+                 * Checks to see if the queue has data in it or not.  Note that there
+                 * is no function to determine the length of the queue.  This data
+                 * isn't kept track of.  If you really need to know, fix this.
                  *@returns True if the queue is empty, false if it has data in it.
                  */
                 bool isEmpty()
diff --git a/src/itoserver.h b/src/itoserver.h
index 60b15b4..729ae7a 100644
--- a/src/itoserver.h
+++ b/src/itoserver.h
@@ -34,6 +34,8 @@ namespace Bu
          * In order to use a Server you must subclass it and implement the pure
          * virtual functions.  These allow you to receive notification of events
          * happening within the server itself, and actually makes it useful.
+         *@author Mike Buland
+         *@ingroup Threading Serving
          */
         class ItoServer : public Ito
         {
diff --git a/src/list.h b/src/list.h
index ec0c195..8152e6b 100644
--- a/src/list.h
+++ b/src/list.h
@@ -25,6 +25,7 @@ namespace Bu
          *@param value (typename) The type of data to store in your list
          *@param valuealloc (typename) Memory Allocator for your value type
          *@param linkalloc (typename) Memory Allocator for the list links.
+         *@ingroup Containers
          */
         template<typename value, typename valuealloc=std::allocator<value>, typename linkalloc=std::allocator<struct ListLink<value> > >
         class List
diff --git a/src/protocol.h b/src/protocol.h
index bca337f..7b69553 100644
--- a/src/protocol.h
+++ b/src/protocol.h
@@ -8,7 +8,8 @@ namespace Bu
         class Client;
 
         /**
-         *
+         *@author Mike Buland
+         *@ingroup Serving
          */
         class Protocol
         {
diff --git a/src/ringbuffer.h b/src/ringbuffer.h
index be80e2f..6a4eecf 100644
--- a/src/ringbuffer.h
+++ b/src/ringbuffer.h
@@ -6,6 +6,9 @@
 
 namespace Bu
 {
+        /**
+         *@ingroup Containers
+         */
         template<typename value, typename valuealloc=std::allocator<value> >
         class RingBuffer
         {
diff --git a/src/server.h b/src/server.h
index 302b6e3..499bf26 100644
--- a/src/server.h
+++ b/src/server.h
@@ -30,6 +30,8 @@ namespace Bu
          * In order to use a Server you must subclass it and implement the pure
          * virtual functions.  These allow you to receive notification of events
          * happening within the server itself, and actually makes it useful.
+         *@author Mike Buland
+         *@ingroup Serving
          */
         class Server
         {
diff --git a/src/serversocket.h b/src/serversocket.h
index b4ee247..751768d 100644
--- a/src/serversocket.h
+++ b/src/serversocket.h
@@ -15,6 +15,9 @@ namespace Bu
          *
          * Although the accept function returns an integral file descriptor, it is
          * designed to be used with the Socket class.
+         *
+         *@author Mike Buland
+         *@ingroup Serving
          */
         class ServerSocket
         {
diff --git a/src/set.h b/src/set.h
index ce2c10a..f35f1f0 100644
--- a/src/set.h
+++ b/src/set.h
@@ -33,6 +33,7 @@ namespace Bu
          *@param sizecalc (typename) Functor to compute new table size on rehash
          *@param keyalloc (typename) Memory allocator for hashtable keys
          *@param challoc (typename) Byte allocator for bitflags
+         *@ingroup Containers
          */
         template<typename key, typename sizecalc, typename keyalloc, typename challoc >
         class Set
diff --git a/src/socket.h b/src/socket.h
index d0949cc..95271f8 100644
--- a/src/socket.h
+++ b/src/socket.h
@@ -9,7 +9,8 @@
 namespace Bu
 {
         /**
-         *
+         *@author Mike Buland
+         *@ingroup Serving Streams
          */
         class Socket : public Stream
         {
diff --git a/src/sptr.h b/src/sptr.h
index bccf887..aac7f48 100644
--- a/src/sptr.h
+++ b/src/sptr.h
@@ -9,6 +9,9 @@ namespace Bu
         template<typename T> class SPtr;
         template< typename Tb, typename Ta > SPtr<Tb> SPtrCast( SPtr<Ta> src );
 
+        /**
+         *@ingroup Containers
+         */
         template<typename T>
         class SPtr
         {
diff --git a/src/tafnode.h b/src/tafnode.h
index 4940bee..585ba73 100644
--- a/src/tafnode.h
+++ b/src/tafnode.h
@@ -10,6 +10,7 @@ namespace Bu
 {
         /**
          *
+         *@ingroup Taf
          */
         class TafNode
         {
@@ -33,6 +34,10 @@ namespace Bu
 
         class TafProperty;
         class TafComment;
+        /**
+         *
+         *@ingroup Taf
+         */
         class TafGroup : public TafNode
         {
         public:
@@ -68,6 +73,10 @@ namespace Bu
                 NodeList lChildren;
         };
 
+        /**
+         *
+         *@ingroup Taf
+         */
         class TafProperty : public TafNode
         {
         public:
@@ -82,6 +91,10 @@ namespace Bu
                 Bu::FString sValue;
         };
 
+        /**
+         *
+         *@ingroup Taf
+         */
         class TafComment : public TafNode
         {
         public:
diff --git a/src/tafreader.h b/src/tafreader.h
index eeaafb3..da285ab 100644
--- a/src/tafreader.h
+++ b/src/tafreader.h
@@ -10,6 +10,7 @@ namespace Bu
 {
         /**
          *
+         *@ingroup Taf
          */
         class TafReader
         {
diff --git a/src/tafwriter.h b/src/tafwriter.h
index f34395e..3e578d8 100644
--- a/src/tafwriter.h
+++ b/src/tafwriter.h
@@ -10,6 +10,7 @@ namespace Bu
 {
         /**
          *
+         *@ingroup Taf
          */
         class TafWriter
         {
diff --git a/src/tests/size.cpp b/src/tests/size.cpp
new file mode 100644
index 0000000..be13b69
--- /dev/null
+++ b/src/tests/size.cpp
@@ -0,0 +1,13 @@
+#include "bu/hash.h"
+#include "bu/fstring.h"
+
+#define pSize( t ) printf("%15s: %db\n", #t, sizeof( t ) );
+
+int main()
+{
+        typedef Bu::Hash<char, char> charcharHash;
+        typedef Bu::Hash<Bu::FString, Bu::FString> strstrHash;
+        pSize( Bu::FString );
+        pSize( charcharHash );
+        pSize( strstrHash );
+}