1. Struct issues in frameset[frame_count]: frame_count isn't in scope, and defining obviously won't work. This is pretty crucial to the whole thing functioning. fixme!
2. In the frame_finder, ya can't declare variables in for() loops. Unless we're in C99 mode. Which we arent.
Also, sframe, eframe, x, and frame_status are undeclared in the function. Or, rather, they aren't in the scope of the function. Make 'em args?
3. status_report_generator has conflicting types.
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.
Master
-Add calls to remotio
-Write more meat into the pseudo-code main() to pull everything together
-Write a 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)
-Write a stub for publishing file and constructing job description so that the job can be shared
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)
Slave
-Fix current bugs
-Add conf-file editing code where commented in register_user()
-Add calls to remoteio, once it works or even before it works
-Figure out how to get output back to the server!
-Add code to write arguments for exec_blender based on the contents of a job's xml file
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
Options
-Rewrite some stuff, try to make it simpler
-Move server and client confuse code into their individual files, rather than in the common file.
-Review all confuse interfacing
-Push patch for relative includes in confuse to the confuse developers