[Gzz] Some thoughts on future directions

[Tuomas Lukka]

... about the future. I know, should be working on the article
but can't before I get these out of my mind.

First, we need yet another name change. When taking the name Gzz,
I felt that we wouldn't stay there - now I know why ;)

In order to keep the nice "PEG" name, we should have a new name
beginning with G as well. Grif? Growl (Emma's)?

Another thing: should we split up the project into subprojects:

- vob framework (extensible, for not all vobs and GL renderables belong here)

- storm

This would make our work more reusable by others, as these do not
depend on each other and would be more readily comprehensible

- xanalogical-media-on-storm base (enfilades &c)

- discrete structure, UIs on the above three 

But of course then we'd need to look for names for all of them.
And we can't use storm if someone's trademarked it in software.
Possibly need to prefix it, as in Growlstorm or something.

Then, the structure. There's something called tuple spaces,
which we should look at.

Basically, most computer languages have the structures:

        - tuple (C's struct, ...)

        - list

        - hash/associative map

Now, there are structures where there are consistency rules.
I think we might want to define these by storm blocks: so that
they really are immutable later, and if a new version is made,
it is a different structure.

The basic unit of the structures is the "point" or "node":
an atomic GUID (urn-5). It has no meaning whatsoever. It's
just a point. 

There are associative mappings, i.e. the "content" mapping
would be a mapping from GUID to enfilade.

The main principle is that all mappings are queriable in any direction.

An important part is that the system needs to keep track
of what relationships are expressed in what blocks, made/*signed* by
whom, and allow limiting of queries by that. This way we can prevent
spamming of a GUID by hostile users.

Should I write these into a PEG?

        Tuomas