////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
// DEVELOPERS:  Architecture and Design Notes
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////

This is primarily a client-server architecture, but all communication is via
	serialized objects over a QSocket.  Furthermore, because status-updates in the
	server must be reflected in all clients, status-pushing was necessary.
	
Essentially what we are left with is a request-driven push architecture, where
	the server sends a QString describing the contents of what will be following.  
	Crude but effective.
	
The current front-end, Face, is a crude approximation of an MVC application.
	
Because some actions generate a TON of traffic (e.g., dragging the track slider),
	a small amount of latency has been added.  This gives the client enough time to
	identify and discard some of the redundant commands.

Although Face and Brain are written with QT, no attempt has been made to 
	make them work with OSes other than Linux.  They do things like look for
	files in /etc and assume that the personal config files follow the unix 
	naming convention of ~/.brain.
	
////////////////////////////////////////////////////////////////////////////////
// Important classes and utilities
////////////////////////////////////////////////////////////////////////////////
--------------------------------------------------------------------------------
-- Classes: Common
--------------------------------------------------------------------------------

Transport
	Uses your QDataStream serial operators, but also pre-buffers so that you
	can be guaranteed that whole objects will be transferred at once.

PlayerStatus
	Just what it says.  Perhaps it should _not_ include track position, because
	that changes constantly.

Playlist
	A representation of the playlist.  Essentially consists of a QValueList
	of QStringLists.  Each QStringList contains the album's serial number,
	the album title, and one string per track.
	
	Note that this is _not_ necessarily derivable from the AlbumDB, because
	it is possible to have partial albums in the playlist.  In essence, though,
	it could be a list of album serial numbers along with an optional list of 
	deviations.  Of course, that wouldn't properly handle things which are 
	absent from the database.
	
Album
	Represents a single album.

AlbumDB
	Represents the music database.  Full of, yup, Albums.  
	Loads/Saves itself, and provides rudimentary accessors, but not much more.

Configurator
	Determines options using config files, environment, and commandline.
	Also provides a nice level-based debugging/logging facility.

ComConf : public Configurator
	Provides options which are common to Face and Brain.

macro DBG(LVL, MSG, __ARGS__)
	Outputs log / debugging text.
	
	Levels: 

    0- Assertion!  Always output.
    1- Status output (may appear on status bar).
    2- Minor status output (may appear briefly).
    3- error conditions
    4- non-error abnormal conditions
    5- major functional steps
    6- function execution except loops
    7- human-readable progress output
    8- common or implicit function execution (including loops)
    9- object dumps, super-verbose loop crap
	
--------------------------------------------------------------------------------
-- Classes: Brain
--------------------------------------------------------------------------------
XmPlayer
	Implementation of the Player as an XMMS remote.  Does all population of 
	Playlist.
	
MServ
	Accepts commands on socket 4336 over the Transport class.  Also accepts raw
	text commands, but this isn't well tested.

MasterDB : public AlbumDB
	Adds self-population to AlbumDB.  Also imports genre and category info from
	cds.txt / cats.txt.

SrvConf : public ComConf
	Provides options which are specific to the server side.

--------------------------------------------------------------------------------
-- Classes: Face
--------------------------------------------------------------------------------
Client
	MVC controller.  Handles network communication as well.  It holds the MVC
	model objects (an AlbumDB, a Playlist, and a PlayerStatus object)  
	and has all responsibility for manipulating them.
	
FView
	It's a view.  It creates and manages the major view components, and organizes 
	communication between them.  Those view components are below.
	
FVInput
	Handles any user input which is not part of standard handling by the view 
	Widgets.
	
FVdb
	Provides services for displaying and filtering the album list.
	
FVPlayer
	Manages the playlist and the player controls.

ClConf : public ComConf
	Provides options which are specific to the client side.

QLirc
	Emits a lirc_action event based on the "config" actions specified in the 
	lirc config file for this application.
	
--------------------------------------------------------------------------------
-- Classes: Deprecated
--------------------------------------------------------------------------------
class TokenStream
	Just like a text stream, but parses into space-delimited tokens.
	Future: permit other delimiters.
		e.g., string=token for config file!
	Hopefully this will be used again later.