Concepts:

- trust: The first model of distren will assume that is can trust all other servers it associates

    with. This removes a great deal of potential complication and yet this should be addressed

    in a later revision of this document.

- server: A process that accepts jobs, manages rendering processes, and talks to other servers

  - server identification: each server must be given a unique, alphanumeric identifier.

      It may make sense to have a server on a machine named after a domain name by which the

      server may be accessed. There doesn't need to be such an association, though. This document

      assumes that a server's name shall also remain constant (anything else would complicate...).

      If a new URL schema would be used, I suppose that distren://<servername>/ might identify a

      distren server.

- job: Represents a collection of renderings that must be unbundled, rendered, and bundled together again.

  - job identification: A server shall internally assign numeric job identifiers. It must only

      make sure that it never issues the same numeric job identifier to multiple jobs. To allow

      multiple servers to share jobs with eachother (which is the the whole point of distren),

      a job shall be refered to by prefixing the job a server identification. For example,

      distren://<servername>/<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>/<jobid>/<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

      in a much shorter time than a single computer could on its own. Many smaller and distinct

      is key to a project being benefited by distren.

  - dependencies: One cannot escape from frame's completion potentially requiring the completion

      of another. Thus, each frame's record must explicitly list the URLs of frames that need to

      be completed prior to the said frame. For a server to complete a frame dependent on other

      frames, those other frames must be transfered to the first server and made available.

  - packaging: To render a single frame and move it about somewhere is normally trivial. However,

      one frame or rendering unit of a given backend may produce multiple files. For this reason

      and for further uniformity and simplification, the data files representing one frame shall

      be transferred using the tarball format.

- client: A distren client is able to submit, query state of, and download completed frames of

      jobs registered in a server.

  - servers: A server, though having many more functions, shall be able to also perform the list

      of actions a client may perform.