distren://<servername>/job/<jobid>

  - job packaging: Currently, the most creative way of dealing with jobs I have at the moment is

      storing all of the data necessary to render the job in a tarball. This tarball can be

      treated as a directory of a normal filesystem. A job's directory would contain at least one

      file called ``distrenjob.xml'' which provides information necessary to render the job. This

      will be an XML file rather than a rigidly defined binary format because XML supports

      arbitrary data storage out of the box. This should allow different rendering backends to

      store the extra information that is specific to that backend.

  - post-render rebundling: Again, to make things simpler, the server where a job is rendered

      shall be responsible for collecting the individual completed frames and collecting them

      into a tarball. This tarball may be called for using a client. This tarball is a bundle

      of completed frames and will exclude the seed tarball.

- frame: Represents a distinct, and hopefully small, unit of work that a renderer backend can perform.

  - frame identification: Like a job numeral is useless without a qualifying servername, a 

      frame's identification number would be useless without an accompanying job identifier. The

      numeric value of a frame identification value must be unique to that job. There are no

      restrictions of ordering of frame numbers except that they are not to be negative. There

      need be no sequencing of frame numbers either. Thus, a frame identification URL would look

      like distren://<servername>/job/<jobid>/frame/<frameid>

  - size: A frame hopefully represents a smaller unit of work in terms of the rendering

      back-end's capabilities. For example, POV-Ray's CLI can initiate and carry out the rendering

      of an entire animation. But distren would hopefully be able to provide a clean method for

      rendering each individual frame and bringing the resulting set of files back to the user

	/> tag is a better example, as povray's .ini file will specify

	the information necessary for a sequence of frames to be

	rendered and we need to actually intercept/override that

	information.

    -->

    <resolution

       width="800"

       height="600"

       />

    <!--

	Currently, for simplicity, there will be a <frame /> tag for

    -->

    <frames>

      <frame name="distren://ohnopub.net/job/36/frame/23" />

      <!--

	  As described in architecture.txt, we allow frame

	  dependencies.

      -->

      <frame name="distren://ohnopub.net/job/36/frame/22">

	<dep name="distren://ohnopub.net/job/36/frame/23" />

	<dep name="distren://ohnopub.net/job/36/frame/24" />

      </frame>