a lot of more thoughts

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

doc/internal/logs/2010-11-09

@@ -41,6 +41,9 @@ 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.
@@ -102,3 +105,76 @@ cdist installation / paths:
 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