I've been thinking a possible open-source development model. I'm having trouble getting the idea winnowed down to elevator speech, so I wanted to write a bit.
The system is built on a peer-to-peer filesystem called Mïmis. Its operation and clients are controlled by interacting with named locations in a collaborative namespace. I'm working on the implementation currently. The basic deliverable is a javascript implemention of:
mimis.read( location, callback )
mimis.write( location, callback )
Where location
refers to a position in the filesystem. For example, I'm working on mapping the spread of businesses. An instruction in that program might look like:
The basic process of handling the call is:
mimis.read
statement.Conceptually, the Mïmis filesystem is a forest of links which contextualize a pool of hashes. In a traditional filesystem, a file is placed in a single directory. In Mïmis, the file is entered into the system and terminates (ideally) any comprehensible path which uniquely identifies it.
I'm beginning to model it by creating a system of links in a filesystem. There's a couple changes that are needed to make it work. The first is using stub filenames. The name of the file is descriptive of the format of the contents of a file, but not its nature. All the "name" information is in the paths.
For example, one path might be: book/by/Nancy Kress/Beggars in Spain/html
. The directory Beggars in Spain
is also linked to from:
Loading html
from any of those locations will load the appropriate file.
Creating the stub form of resource names is generally pretty straightforward. For example, consider the contents of my image collection. When I started I had files like:
Converting them to stub form they become:
Each directory contains a ...
subdirectory which is a symlink to ../...
. The one exception is the root of the filesystem where ...
is a link to .
.
Structurally this creates a tree that looks like:
Algorithmically, what this structure allows is trees
All binary files are stored as links to .../hashes/
The Neo4j instance serves to aggregate multiple filesystem sources. The base source
Alice gets a new scanner, plugs it in, starts the scanning software, clicks scan
and gets the error:
If they click no
, they get some snippy comment about the nature of electronic devices.
If they click don't know
, they get appropriate instruction/options for connecting. Eventually they get back to this question with the ability to answer yes
.
If they enter yes
they might get some further diagnostic questions, but eventually end up they end up with the choice to escalate the issue.
Developers have a queue of messages to potentially act on. When a user escalates an issue, it is pushed into some of those queues. Information is gathered through question messages. One type of those is a fuzzy tag. For example, one question useful for determining which queues to place a trouble ticket would be:
The first level above a novice user is a diagnostician. This is someone with the technical expertise necessary to narrow an amorphous user complaint into a usable bug report. Advanced users might well not need an intermediate. The goal is to produce some set of development needs expressed as:
to prepare a properly descriptive bug report. For example, Alice needed a feature request created. A variety of pages might be collected, but one of them will be a stub message that looks something like: