DOC: decide to pull through with the layer renaming

doc/devel/rfc/LayerNames.txt

@@ -5,7 +5,7 @@ LayerNames
 
 [grid="all"]
 `------------`-----------------------
-*State*         _Idea_
+*State*         _Final_
 *Date*          _Fr 05 Oct 2018 15:05:58 CET_
 *Proposed by*   Ichthyostega <prg@ichthyostega.de>
 -------------------------------------
@@ -62,8 +62,8 @@ Tasks
 ~~~~~
 // List what needs to be done to implement this Proposal:
  * find convincing new names ([green]#✔ done#)
- * update and add documentation [yellow-background]#WIP#
- * adjust source folders and namespaces [red yellow-background]#TBD#
+ * update and add documentation ([green]#✔ done#)
+ * adjust source folders and namespaces [yellow-background]#WIP#
  * adjust build system and library names [red yellow-background]#TBD#
  * fix textual usage in code and documentation [red yellow-background]#TBD#
 
@@ -149,8 +149,60 @@ Comments
 --------
 //comments: append below
 
+.Mail Thread
+[quote]
+____
+
+ Subject: Re: Aw: Re: Session
+ Date: Sat, 15 Sep 2018 10:29:11 +0200
+ From: Benny Lyons <benny.lyons@gmx.net>
+ To: Ichthyostega <prg@ichthyostega.de>
+
+ > On 14.09.2018 22:37, Ichthyostega wrote:
+ > Du bringst hier einen Punkt zur Sprache, der mir auch schon länger durch den
+ > Kopf geht, Benny. Eigentlich sind die Namen für unsere Layer etwas "daneben".
+ > Sie sind nicht wirklich gut. Zum einen klingen sie etwas dröge (vor allem
+ > "Proc"), und etwas, mit dem man so viel arbeitet, sollte doch auch inspirieren ;-)
+...
+ > Ein anderer Ansatz, der mit auch immer mal wieder durch den Kopf geht,
+ > ist, ob wir nicht sogar metaphorische, oder symbolische Namen wählen sollten.
+ > Etwas, was man vielleicht auch nicht gleich versteht, was aber die Phantasie
+ > anregt. Meine Favoriten wären da (Du weißt, was für Filme ich mag....)
+ > 
+ > - Stage
+ > - Steam
+ > - Vault
+
+Die finde ich sogar gut, sogar sehr gut. Warum nicht!
+Wenn wir die Meinug sind, dass wir keine zutreffende Beschreibung in
+einem Wort finden können!
+``Stage'' wurde erfogreich in Git von ``Index Area'' umgenannt. 'Stage' und
+'Vault' sind sehr gut, 'Steam' obwohl gut, erreicht nicht die Hohe von 'Stage'
+und 'Vault', meiner Meingung nach.  Können wir etwas finden die eine
+Verbindung zwischen Stage und Vault  herstellt, sowas wie Backstage
+(wollen wir natürlich nicht), Make-up, Props, ... alles natürlich nicht
+gut, aber Du weisst was ich meine.
+
+Aber Du sprichst eine sehr guten Punkt an. Mit ``Backend'' könnte jeder
+etwas darunter vorstellen, aber ``Proc Layer'' war nicht besonders gut.
+Hmm! ist aber wichtig, das können wir nicht nur hier machen. ABER übliche Namen,
+die im alten Schneiderraum benutzt wurden, müssen
+immer fanatisch eingesetzt werden. Alte Profis müssen sich sofort wohl
+finden.
+____
+
+
+.State -> Final
+//add reason
+This is not really a ``RfC'', to be honest. Rather I am pulling this off now.
+I am working solitary on the coding, which has the benefit that I can settle
+such global matters without much further ado...
+
+Ichthyostega:: '2018-11-15 19:38:32 +0100' ~<prg@ichthyostega.de>~
+
 
 //endof_comments:
 
 ''''
 Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
+

doc/devel/rfc/SchedulerRequirements.txt

@@ -12,13 +12,13 @@ SchedulerRequirements
 
 ********************************************************************************
 .Abstract
+Define the expected core properties and requirements of the Scheduler service.
+********************************************************************************
+
 The rendering and playback subsystem relies on a Scheduler component to invoke
 individual frame rendering and resource fetching jobs. This RfC summarises the
 general assumptions and requirements other parts of the application are relying
 on
-********************************************************************************
-
-Define core properties and requirements of the Scheduler service.
 
 Description
 -----------

doc/technical/code/c++11.txt

@@ -284,7 +284,7 @@ notorious techniques for detecting a function work well on conventional lambdas,
 And it is not possible to ``probe'' a template with SFINAE: If you instantiate a template, and the result is not
 valid, you've produced a _compilation failure_, not a _substitution failure._ Which means, the compilation aborts,
 instead of just trying the next argument substitution (as you'd might expect). Another consequence is that you
-can not _just accept a generic lambda as argument and put it into a `std::function` (which otherwise is the
+can not _just accept a generic lambda as argument_ and put it into a `std::function` (which otherwise is the
 idiomatic way of ``just accepting anything function-like''). In order to place a generic lambda into a `std::function`,
 you must decide upon the concrete argument and return type(s) and thus instantiate the template at that point.