# HG changeset patch # User Nathan Phillip Brink # Date 2010-07-22 20:56:40 # Node ID aac883811d59a6afc7799e0d3505d1888428d763 # Parent 92659c5651efd26d49106f365adbd7fc7b999573 Added some documentation describing my ideal for distren's architecture. diff --git a/doc/architecture.txt b/doc/architecture.txt new file mode 100644 --- /dev/null +++ b/doc/architecture.txt @@ -0,0 +1,58 @@ +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:/// 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:/// + - 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://// + - 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.