1. Create a CLI interface for distren
	X command: distren
	X args: -i infile.tar.bz2 -o outfile.tar.bz2 
	action: submits and blocks and retreives result of rendering the contents of infile.tar.bz2. Should currently just call stub functions.
	
2. Design of stubs in distren library:
   	X Stub for submitting file to server
	WIP Write configuration loader
	Stub for submitting file to a server (using a stream)
	Stub for waiting for server -> Maybe the client can just poll? I've got to decide this.
	Stub for retrieving result (using another stream)

3. Design of stubs in distrend:
	Stub for getting info from the tarball/validifying the tarball. Read distren-job.xml, a file in the tarball, to find out 1. which rendering system to use (that system, e.g. blender/povray, can read more specifics, such as name of file to pass to blender and frames. Options common between different systems will be handled in common as best as possible)
	Storage of data + metadata: Stubs for unpacking tarball, assigning the submission an ID, and retrieving the file by the submission ID.
	Actual rendering: Stub for calling subsystem's action that does the rendering. The subsystem should accept an XML fragment (a libxml subtree) that is specific to the subsystem. Ideally, subsystems will be both pluggable at both the dlopen() and link-time levels. dlopen may actually be easier than link-time pluggables...
	Stub for submission of new jobs to be distributed (a subsystem rendering a file with multiples frames should generate a subjob for each frame)
	Stub for publishing file and constructing job description so that the job can be shared