define second stage provider run

Signed-off-by: Nico Schottelius <nico@yoda.schottelius.org>

doc/internal/provider-integration

@@ -42,20 +42,52 @@ attributes.
 
 
 
+--------------------------------------------------------------------------------
+provider layout:
+
+   <name>/
+      config   # binary that is called to adjust cconfig tree
+      change   # binary that is called on the remote host?
 --------------------------------------------------------------------------------
 cdist view on providers:
 
 How providers are integrated/run:
 
+   First stage:
    - If cdist encounters provider in manifest,
      a wrapper script is run, that creates a
      new entry in the cconfig database and adds
-     attribute values:
+     attribute values. This defines a cconfig
+     tree, that may look as follows:
       
-      conf/__file/cdist_bin/source
+      <hostname>/<provider>/<id>/<parameters>:
-      conf/__file/cdist_bin/destination
+
+      myhost/__file/cdist_bin/source
+      myhost/__file/cdist_bin/destination
+      ...
 
    - In this stage, no conflicts may occur, as
      no provider code has been called (i.e. only
      manifests, which map config to hosts is
      applied).
+
+   Second stage:
+   - The "manifest" script of every used provider
+     (i.e. the manifests created at least one object)
+     is called, which again is able to call other
+     providers. All created objects may also be modified
+     by the provider.
+
+     For instance a "httpd" provider may call the
+     "webroot" provider with --path / ... 
+     # FIND CASE WHERE SENSEFUL => look through
+     current puppet config
+
+   - The newly created objects are merged back into
+     the existing tree. No conflicts may occur during
+     the merge, because this would implicit that the
+     provider conflicts with other providers.
+
+     The idea of this that a provider may expand another
+     provider with functionality, but may need to adjust
+     ("overwrite") settings from the original provider.