promote the Engine Interface Overview to draft state

doc/design/architecture/playRender.txt

@@ -40,23 +40,23 @@ Now, we need to shorten that into a single word. The more obvious
 abbreviation (just by the importance) would be _Render_, but that
 would be strikingly misleading, because everyone would take that
 to be the render engine. Which leaves us with _Player_. A second
-consideration shows us that the structure of that subsystem will
-be very close to the structure of any software player -- the chosen term
-turns out to be well aligned with the actual nature of that subsystem.
+consideration highlights similarities with the structure of a
+typical software player -- the chosen term turns out to be well
+aligned with the actual nature of that subsystem.
 
 Influences and Requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In accordance with the spirit of modern software development, the analysis
 starts by determining which would be the _Service_ to be provided by such
-a player. Consideration of the use cases highlights the fundamental forces
+a player. Consideration of the use cases determines the fundamental forces
 to be _multiplicity_, combined with _differentiation in detail_, all under
 the government of _time-bound delivery_, combined with _live reconfiguration_.
 
 The basic service turns out to be the *performing of a preconfigured object model*.
 This performance is *time based*. Multiple usage instances of this service can
 be expected to coexist, each of which can be broken down into a set of *elementary
-streams to be delivered synchronously*. The delivery mode can be *reconfigured
+streams to be delivered in sync*. The parameters of delivery can be *reconfigured
 on-the-fly*.
 
 Modes of operation

doc/devel/rfc_pending/EngineInterfaceOverview.txt

@@ -1,6 +1,12 @@
+Engine Interface Overview
+=========================
+:Date: 2010
+
+// please don't remove the //word: comments
+
 [grid="all"]
 `------------`-----------------------
-*State*         _Idea_
+*State*         _Draft_
 *Date*          _2010-04-16_
 *Proposed by*   link:Ichthyostega[]
 -------------------------------------
@@ -8,11 +14,14 @@
 
 Overview Engine Interface(s)
 ----------------------------
+
+********************************************************************************
 At the Engine Interfaces, Lumiera's Backend and Session get connected and work
 together to produce rendered output. This design proposal intends to give an
 overview of the connection points and facilities involved, to define some terms
 and concepts and to provide a foundation for discussion and working out the
 APIs in detail.
+********************************************************************************
 
 
 
@@ -26,8 +35,7 @@ Participants
  *Scheduler*:: cares for calculations actually to happen, in the right order
   and just in time, if at all
  *Node*:: abstraction of an processing unit, supports planning by the
-  dispatcher, +
-          allows to pull data, thereby driving the actual calculation.
+  dispatcher, allows to pull data, thereby driving the actual calculation.
 
 Render Process
 ~~~~~~~~~~~~~~
@@ -62,7 +70,7 @@ identifier and _channel selector_.
    
  timings::
    a definition to translate global model time units in real clock time,
-   including _alignment_ to an external time grid.
+   including _alignment_ to an external _time grid_.
    
  model port::
    a point in the (high level) model where output can be produced. +
@@ -166,7 +174,7 @@ prerequisites)
 Node Invocation API
 ~~~~~~~~~~~~~~~~~~~
 As nodes are stateless, they need to be embedded into an invocation context in
-order to be of any use. + The node invocation has two distinct stages and thus
+order to be of any use. The node invocation has two distinct stages and thus
 the invocation API can be partitioned in two groups
 
 Planning
@@ -175,8 +183,8 @@ During the planning phase, the dispatcher retrieves various informations
 necessary to _schedule_ the following pull call. These informations include
 
  * reproducible invocation identifier, usable to label frames for caching
- * opaque source identifier (owned by the backed) when this node represents a
-   source
+ * opaque source identifier (owned by the backed) in case this node
+   represents a source
  * prerequisite nodes
  * index (channel) of the prerequisite's output to be fed as input buffer(s)
  * number and size of the output buffers required
@@ -201,11 +209,13 @@ Node pull
 Tasks
 ~~~~~
  * find out if we need to support variable framerate
- * find out about the exact handling of multichannel data streams
- * design a buffer descriptor
- * design a buffer designation scheme
- * expand on the node identification scheme
- * clarify how control data frames can be addressed
+   ([green]#->  yes, implementation deferred#)
+ * find out about the exact handling of multichannel data streams ([green]#✔ done#)
+ * design and prototypical implementation of frame quantisation ([green]#✔ done#)
+ * design a buffer descriptor [red]#TODO#
+ * design a buffer designation scheme [red]#TODO#
+ * expand on the node identification scheme [red]#TODO#
+ * clarify how control data frames can be addressed [red]#TODO#
 
 
 Discussion
@@ -229,17 +239,28 @@ Rationale
 
 
 
+//Conclusion
+//----------
+//conclusion: When approbate (this proposal becomes a Final)
+//            write some conclusions about its process:
+
+
+
 
 Comments
 --------
+//comments: append below
 
-////////////////////
+.State -> Draft
+Requirements and details of the design are sufficiently clear meanwhile.
+Ther seems to be not much room for alternative approaches, given our
+general planning for the application
 
-Conclusion
-~~~~~~~~~~
-* *accepted* / *dropped* by MMMMMM.YYYY developer meeting.
-
-////////////////////
+    Mi 11 Mai 2011 19:27:12 CEST Ichthyostega <prg@ichthyostega.de>
 
 
+//endof_comments:
+
+''''
 Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
+