todo.yaml

Issues:
  - What is 'normal' action invocation? Where action arguments should go?
    - Prefer to use target as an argument
      - 'foo.bar: remove' instead of 'foo: remove bar'
    - >>> Prefer to logical order/actual topology instead of target
      - 'foo: exists bar' instead of 'foo.bar: exists'
    - Valid basic action calls
      - 'foo.bar: get'
      - 'foo.bar: set 123'
      - 'foo.bar: create spam'
      - 'foo.bar: create spam 123'
      - 'foo.bar: list'
      - 'foo.bar: exists spam'
      - 'foo.bar.spam: exists' (this will always return True or throw an exception if 'spam' doesn't exists)
      - 'foo.bar: remove spam'
      - 'foo.bar.spam: remove' (if 'foo.bar.spam' exists for sure - throw exception if not)
  - Where and if action call normalization should happen?
    Normalization in this context means different behaviour depending on number of action parameters, i.e.
    'foo.bar: remove spam' should be semantically equal to 'foo.bar.spam: remove' (or other way)
    - Normalization should be handled by the invoked action
  - Should build-in, layer-dependant actions have representation in the tree?
    - Yes - this will allow their overriding
  - Network session reequirements
    - Attachement of an remote tree
      'create.connection .remote 10.0.0.2'
      '.remote: connect'
    - Detachement of an remote tree
      '.remote: disconnect'
      'remove .remote'
    - Argument forwarding to remote tree
      '.remote.hour: set 18' should invoke '.hour: set 18' on the remote host
    - Return value forwarding
      '.remote.minutes: get' should return value to the local system
    - Action arguments can be represented as tree
      E.g "foo bar=123 bar.spam=arg" will result in following argument tree
      """
      [0] foo
      bar 123
      bar.spam arg
      """
    - How to pass argument tree into action?
      - >>> Serialization into ordered dictionary
        - Easy to implement
        - Backward-compatible with common functions
      - Path to the temporary tree
        - Requires backend to support temporary trees
        - E.g. File backend would require temporary files just for arguments
      - New tree type
        - Requires architectual change?
    - What data is passed to the action on invocation?
      - Target path
      - Action name
      - Arguments
      Note: Tree/Root is not passed as it doesn't change between invocations
    - How to implement dynamic actions?
      'create' action could have dynamic sub-actions which represent installed types.
      For example 'create.int', 'create.link', 'create.action.alias', etc;
      - Sub-actions with no direct representation in node tree
        could be forwarded to the parent action - 'create.*' -> 'create'
      - When resolving action, custom commands should be used;
        Resolving 'create.foo.bar' would require resolving 'create', then
        'create: list' need to contain 'foo', then 'create.foo: list' would contain 'bar'
    - What is difference between TreeRoot and NodeType?
      - both contain actions which are valid for their 'mount-point'
      - TreeRoot provides data-storage backend, while NodeType should use existing storage backend
    - How to provide actions/types for TreeRoot which doesn't support @action nodes?
      - TreeRoot's execute method, may throw when method is not found, ater this, next-in-hierarchy treeroot is being searched

Filesystem backend:
  - Custom types for different files
    - (Virtual) Attributes generation
  - Can be root backend (so different system actions will be accessible via /system/...)
  - Access to existing (raw) programs ($PATH directories should be included in some @actions)

Network backend:
  - Commands issued are executed on the remote host

Tree backend:
  - Serialization to file
    - Values
    - Actions
  - Type safety
    - Action parameter tree (generation?)
    - Action argument validation according to parameter tree
  - Read-only nodes
  - In-tree links support?
  - Easy creation of custom nodes from python classes
    + @action decorator
  - Actions should take target node/path and argument tree (instead a list which is currently used)
  - Virtual attributes
    - @name
    - @path
    - @parent
  - Add 'Node.' prefix too all node-related actions
  - Customizable search path (or virtually merged branches)
  - Sessions/TreeViews
  - Server-client architecture
  - Index addressing
    - Anonymous (without name) nodes

Functionality:
  - Sessions:
    + Virtual mapping node - kind of a link
    - Temporary
      - select(ed)
      - copy/cut/paste
      - user session separation
    - Transaction
      - system settings update
    - Network transport
    - Security/permissions
    - Filesystem mapping?
    - virtual attributes?
  - Self-awareness - .contexttree (or similar) branch
  - Date/Time node
    - System time reading
  - Filesystem mapping
    - System executables as actions
    - copy, cut and paste actions (using select(ed) action?)
    - mime-type based file typing
  - Types support
    - Introspection commands
      - is
      - typeof
  - create.int
  - create.string
  - create.link
  - create.<type>
  + list.attributes
  - list.actions
  + list.all
  + list.nodes
  - select/selected
    - temporary/session storage
    - links
    + anonymous keys

Shell:
  - Autocompletion/suggestions
  - Server-client architecture
  - Branch navigation action (aka cd); should be in session?
  - Command invocation wizard (based on command's parameter tree)
  - set syntax sugar - .some.key = 321
  - get syntax sugar - .some.key (should be translated to .some.key: get if possible)
  - Command output streaming - list | filter | ...
  - Named streams
    - list |> {stream l}
    - {stream l}: filter
  - Field streaming - {list}|.@name (based on command output streaming; filter?)
  - Batch calling - {selected}: play