re-integrate log directory

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>

doc/dev/logs/2010-11-09

@@ -0,0 +1,180 @@
+Rethinking ideas of last talk.
+
+What if types are formal / have formal arguments?
+What if cdist can do all the parsing stuff and the real
+functionality comes out of the library (similar to cfengine)?
+
+What if the library is integral part of cdist?
+
+
+conf/lib/$name/
+   attributes/
+      a
+      b
+      c
+
+
+--------------------------------------------------------------------------------
+I'm not sure whether this design is in fact helpful.
+But it's clearly necessary to have a directory per type, so a type can
+have helpers.
+
+
+conf/lib/$name/
+   init?
+
+
+Prepare some very minimal (non functional) framework for library integration?
+   Like parsing for command line arguments?
+
+--------------------------------------------------------------------------------
+Real configurations versus types:
+
+Types are reusable code: For instance etc_resolv.
+
+Configurations are types used and configured.
+
+
+--------------------------------------------------------------------------------
+
+Style
+
+   __type <id> --option1 <arg1> 
+
+   <id> = everything your filesystem permits, but may not start with a period (".").
+   If <id> == ., it setups the standard attributes.
+
+seems to be quite good usable. cdist can easily -----parse--- this.
+
+Nope. We don't parse. We let the shell execute.
+
+So whatever is __type will get executed.
+
+__type must probably be part of some cdist specific path.
+
+Which again could be
+
+   conf/lib/$name
+
+Which could result in the directory
+
+   conf/lib/.$name for helpers
+
+That style could include a mandority --help, --args arguments
+and would thus be independent of the language used (can, but does
+not must be shell).
+
+How to solve standard configurations that way?
+
+   EASY AS WELL!
+
+   __type <either option or magic> --option1 <arg1>
+   
+   for instance
+
+   __type . --option1 <arg1>
+
+
+--------------------------------------------------------------------------------
+Type paths
+   At least (at maximum)? 2:
+      user + system
+
+   Easy to do.
+
+--------------------------------------------------------------------------------
+Types: Name types types or name types modules?
+
+--------------------------------------------------------------------------------
+
+Where to place/start the configuration?
+
+   wherever it is: name it configuration!
+
+
+--------------------------------------------------------------------------------
+cdist installation / paths:
+
+   /etc/cdist/                   # CDISTBASEDIR
+      config/                    # CDISTCONFIGDIR
+      types/                     # CDISTUSERTYPEDIR 
+
+   $prefix/lib/cdist/types/      # CDISTSYSTYPEDIR
+
+
+cdist environment:
+   $__loaded_from                # path where $type has been loaded from
+   PATH=$CDISTUSERTYPEDIR:$CDISTSYSTYPEDIR:$PATH
+
+--------------------------------------------------------------------------------
+Recommendation (not a must):
+   Put helpers for types into the typedir/.$typename
+
+   All types should be prefixed by "__" to prevent clashes with the system
+   binaries.
+--------------------------------------------------------------------------------
+Type commands (__bla) could get generated by cdist and cdist could use that
+to generate the actual cconfig part.
+
+This leads up to the next section
+
+--------------------------------------------------------------------------------
+How to write my own type named "coffee":
+
+   Create the directory /etc/cdist/types/coffee/
+   Create the file /etc/cdist/types/coffee/README containing a description of the type.
+   If your type supports attributes, create the directory /etc/cdist/types/coffee/attributes.
+   For each attribute, create the file
+      /etc/cdist/types/coffee/attributes/$attribute_name which contains
+
+      a short description on the first line
+      then a blank line
+      then a long description (probably over several lines)
+
+   If you think your type may be useful for others, submit it for inclusion
+   into cdist at cdist -- at -- l.schottelius.org.
+
+   Create /etc/cdist/types/coffee/init which reads $configinput
+   (either via cconfig or via environment) and outputs a block of
+   shell code suitable for running on the client.
+
+
+--------------------------------------------------------------------------------
+
+cdist exec steps:
+
+   - check for valid types, abort if user (re-)defined system types
+   - generate __type binaries (aliases?), which contains cdist logic
+     to analyse types and check for correct arguments
+   - execute /etc/cdist/config/init (MAIN CONFIG) which in turn
+     calls __type binaries
+   - __type binaries (which are all the same, multicall!) generate
+     cconfig
+   - Run real type/init binaries with respective cconfig dir as path,
+     which must generate shellcode to be executed.
+   - Create the temporary shellscript containing all the code and execute
+     it on the client.
+
+--------------------------------------------------------------------------------
+Support metaargs like --depends?
+   If so, they need to be forbidden for types.
+--------------------------------------------------------------------------------
+Shell code generator:
+
+   - use subshells for each shellcodeblock
+   - create one main function (to ensure transfer is complete)
+
+Example:
+
+cdist_apply_$hostname()
+{
+
+   # repeat this block for every type/id defined
+   echo "Executing block from $type_$id ..."
+   (
+      code
+   )
+
+}
+
+cdist_apply_$hostname