How do you build a rolon?

A rolon (or a role) isn't an easy thing to build. I've been trying for 4+ years. AW topics are close but, for example, they lack fine control over applicative order. They're good enough to do a lot of things, but they build on TKCS, which is a bit of a mess.

A structure of tables seems to be what is needed, where a table is both a dictionary and an ordered list of key/value pairs. One of the tables in a rolon would be the classifiers, which would hold the parents, includes, tags, color, names and the DescriptorUnit. Entries in a classifier table would be distinguished by the key prefix. And yes, the list is ordered, not sorted. (There may actually be two classifier tables, with a separate one for non-"-" tags and color, as these do not impact the applicative order.) I've been calling these the normal tables. All the other tables referenced by a classifier table would be the top-level table of other rolons.

Another table would be the instance descriptors. Instance descriptors would, for example, control display and determine if a given type of children are ordered or sorted.

There would also be tables for the various types of children--i've been calling these tables the external tables, as they hold links to other rolons (i.e. the top-level table of other rolons) and define the non-cyclic graph of rolons.

Then there would be the top-level table (the root table for the rolon) which references all the other tables in the rolon. I've been calling this the internal table, because all its links to other tables are internal to the rolon. This is also where, for implementation purposes, I would keep the rolon name, though the name is really a classifier.

Of course, all this would be change based, where the actual state of the table depends on the given time (current or past). So the whole thing gets built on something like TKS.

And ipso facto, we have a pretty fair implimentation of basic rolonic theory. And the perfect thing to implement an AgileWiki (or just about anything you can imagine) on top of.

What did I leave out? The journal! This is a hard one to describe, as it is built on the transactional mechanism used by TKS. Basicly every transaction/JournalEntry is

1. a set of changes, which are applied to various tables in one or more rolons, as well as
2. the command which invoked those changes,
3. the rolon which was the context for the command,
4. the time of the change,
5. a unique transaction identifier (a UUID), and
6. the user who entered the command.

By Grorge, I think I've got it! A one-pager describing (at a high level, I'll grant you) how to implement a rolonic system.

I guess this wasn't such a bad day, after all.

bill