- parameter/setting default from manifest
    ==> BRANCH[feature_default_parameters],
    ==> PERSON[Steven or Nico]
    ==> PROPOSAL(1)
    - current bug
    - proposal 1: parameter/default/$name (for optional ones)
        - new way
        - catches --state absent|present
        - needs changes of types
        - also possible for explorer
        - support for it in core?
            - handling of ${o} $o "$o" ?
            - handling which variables?
            - introduction of "templating language"
                - aka macros
                - possible problems:
                    - inconsistency
                    - redoing shell functionality
                    - raising expectations for more templating from users
                - possible benefit
                    - no need for eval
                    - once in core, not everytime in type
                        - OTOH: one extra word. 
                        - a=$(cat $__object/parameter/name) vs. $(eval $(cat $__object/parameter/name))
        - only possible for static defaults
            - --name overrides name not possible vs. object_id
                - Is this the only case????
                    - if yes: don't care.
                - possible solution:
                    - echo '/$__object_id' > typename/parameter/default/name
                    - eval $(cat $__object/parameter/name)
                        - probably allows code injection
                            - is possible anyway???
                            - $(cat /etc/shadow)
                        - other eval side effects???
                            - none: go for it
                            - some: have headache
                            - many: don't do
    - proposal 2: 2 dbs (user input vs. stuff changable by type)
        - explicit 2nd db [parameter_user and parameter/]
        - not very clean (both agreed)
    - proposal 3: parameter are read-only
        - breaks current types (in core probably elsewhere)
        - can't enforce, but user is on his own => breaks, her problem
        + clean seperation between core and type (nico)
            - parameter belongs to type not core (steven)
    - proposal 4: core ignores changes in parameter/* of object
        - implicit 2nd db [see automagic below]
        - steven+++
        - does not work with divergent emulator not being in core
            - because emulators primary db __is__ fs.

1 manifest:

__foo bar == emulator
echo present > $__global/object/__foo/bar/parameter/state

# fails
__foo bar == emulator

! automagic / filesystem
    ! fsproperty:
        - kill, write explicitly to disk
    ==> BRANCH[cleanup_fsproperty]
    ==> PERSON[Steven]
    ==> PROPOSAL(just cleanup)

    - implicit/automatic writes/read to fs
        - explicit interfaces are better then implicit
        - same problems as in cdist 1.x to 2.x move! (environment!)
    - format on disk should not change/dictate code flow
        - degrade python to shell (nico++! steven--)
            - user should not care about python, ruby, .net or ASM implementation (steven++ nico++)

    ? proposal 1: diverge emulator / core
        - emulator verifies input
        - emulator writes to fs
        - core reads/syncs from/to fs before passing control to user

    ? proposal 2: emulator is dumb and passes data to core
        - core creates objects
        - no fs involved
        - core reads/syncs from/to fs before passing control to user
        - passing:
            - full objects via pickle
            - parameters only
            - how???
                - unix socket?
                    - not everywhere possible?
                - tcp / ip
                    - not everywhere possible
                        - chroot / local only
                - rfc 1149
                    - not everywhere possible
                        - missing avian carriers
                - 0mq
                    - not everywhere possible
                        - not installed
                - shm (ipcs and friends)
                    - not everywhere possible
                        - no /dev/shm, different libraries? cleanups needed...
                - what speaks against FS?
                    - emulator_input/.../

                - nico: to fancy probably

! boolean implementation
    ==> BRANCH[feature_boolean_parameter]
    ==> PERSON[Steven]
    - nico: 
        - parameters/boolean: document
        - argparse changes (consider parameters/boolean)
            - create 
    - can be implemented with changes in emulator
        - use store_true, del if false => never seen by core
    - INDEPENDENT INDEPENDT OF FS.PROPERTIES!!111111!

- emulator:
    - how much integrated into core
        - also: using CdistObject????
    - dependency on filesystem: good (nico) | bad (steven)

- singleton / support without object_id
    - not discussed

- __apt_ppa:
    ==> BRANCH[bugfix_do_not_change_state_in_manifest]
    ==> PERSON[Nico]

- logging divergent between emulator / core
    - no problem (nico)
    - may be helpful (steven)