Projecting Views

This article is WIP, expect informal language and vague descriptions

This workflow is a logical consequence of the following features:

• Data grouping
• Group level xattrs
• Configurable stores

Background

This workflow is rooted in a rejection of directory trees as the way to organize data because they are structures of stagnation, created at the whims of subjective actors, and they do not scale.

• Stagnant because directory trees capture exactly one organization scheme
  • Any mistakes incurred at the planning of the structure taxes all workflows until it is fixed
  • The longer a sub-optimal solution is tolerated, the higher the cost of fixing it, a vicious cycle
• Subjective because an operator's concept of "optimal" is subject to their browsing habits
  • A pure example is that reasonable people can disagree whether photos should be grouped by what is depicted or related events
  • The problem also applies for failure to anticipate workflows that doesn't yet exist
• Unoptimized trees has the worst performance and discoverability characteristics because they are inconsistent
  • A directory tree of sufficient size will be useful to no-one. This is because trees naturally occlude one's perception and the only widely supported search feature is file names.
  • Combined with the fact contents tend to influence how people explore a tree, the logical consequence is branches that are rarely if ever visited

Concept

Consider the database. A centralized storage of data, projected into many views, each optimized for a particular workflow.

• Data is identified by many properties (as opposed to one path). Individually observable, meaningful descriptors of the data
• Views are derived from rules that organizes data based on their properties
• Should requirements change and a view ceases to be optimal it is trivial to define new rules and a replacement brought up in moments
• Should a view be corrupted, nothing of value was lost, it could be recreated at any time