accumulate reduce navigations

[plastikfan]

The current navigation process is stateless. That is to say, during a navigation, each individual client invoke is independent, there is no state linking all of them.

Without state, an operation equivalent to the standard unix tree command is not possible. What is needed is some kind of reduce navigation which requires the use of an accumulator; similar in concept to the reduce operation in functional programming. This concept lends itself well with this particular requirement.

So in order for commands like 'tree' to work, we need to provide the framework that allows this:

• The client handler needs access to an accumulator.
• A field called accumulator is set on the servant
• Because the accumulator can be of any type, this type can’t be something that agenor is aware of so it will have to declared as any and it will be up to the client code to cast. it to the appropriate type, as they will know
• Like the functional reduce command, there needs to be the facility to provide an initial value of the accumulator. This should be provided before the navigation starts.
• at the end of navigation, the accumulator needs to be available to allow 'end of file' type of content to be added, eg a summary.
• For operations that generate a file as a result of the navigation, eg a script to perform rename batch, the accumulator would probably be a string buffer. Theoretically 'reduce' sub commands knows the type and can cast accordingly.
• Theoretically, the accumulator can be accessible to walk and sprint, however, for the latter, it will only make sense to have an accumulator when order of execution/completion is insignificant.

Here are the issues regarding population of an output file:

• For reduce operations that require writing to a file for every visited node, we need to be careful about the output file as the navigator is created with a virtual file system and so paths are relative to the tree root. If we allow the client to have direct access to the output file, then a full resolvable path (either a full path, or a relative path that can be resolved to a full path), would have to be made available to the the client, perhaps by a new property on the node Extension.
• Typically we would want to restrict the output file to be outside the navigation directory tree.
• If we continue with the approach of using a relative file system for the output file, this would mean that another tree (output-tree) be added to the forest, so another path can be defined relative to the output-tree.
• An alternative to a relative a output file is you provide the client callback to add content, and the navigator itself would add the content to the output file on the behalf of the client.
• Or the navigator manages creation of the file but provides the client callback with the file handle representing the output file. Use of a shared file like this, would mean this approach would be strictly limit to walk operations as a sprint operation would mean there would be concurrent contention to the same file, which will result in unexpected results.

This successful outcomes of this task are

• provide a facility so that a command can register its requirement for an accumulator, so that the navigator knows that a reduce type traversal is occuring
• add a new output tree to the forest
  This would include adding the full output path to the node Extension
• add opaque accumulator field to servant
  This would include providing the facility to initialise the accumulator before navigation starts and presenting the accumulator to some kind of life cycle event at the end of the navigation

---

IMPORTANT: issues to be resolved (not an agent decision):

• file system: alternative output file system; bridging between different file systems