[vos-d] vos-d Digest, Vol 52, Issue 4

[Andrew Robbins]

I'm replying both to "thoughts and plans" and "3D engines" posts. I have 
also been thinking about similar things, and I agree with the desire to 
combine Emacs+Mozilla ideas. I have also been thinking a great deal 
about tables, tags, trees, and types (talk about illiteration!). The 
reason I've been thinking so much about them is that every once in 
awhile, I'll come up with a new way of converting between one or the 
other. For example, unlike flickr.com tags, if there was a primary tag 
and a secondary list of tags (and you could tag tags with tags), then 
this kind of tag-based system would be isomorphic to a tree-based system 
(like directory structure) represented as a folder (representing the 
primary tag) containing the item, with symlinks to this item in other 
folders (representing the secondary tags). The only problem with this 
isomorphism is that tag-based systems usually have an implicit global 
namespace.

Anyways, about the engines. The talk about the engines reminded me of a 
pattern I noticed in both my thoughts and in the Gtk+ system. There is 
an added bonus of extensibility when there are two layers of abstraction 
for plugins rather than just one. In the Gtk+ system there are 
GtkEngines and GtkThemes, and iirc, given a GtkEngine you may have any 
interface you want for a GtkTheme, which means given a GtkTheme, there 
may be only one GtkEngine with which it will work. So instead of 
designing a VosBrowserContentPlugin interface and a VosBrowserUiPlugin 
and a VosBrowserScriptPlugin interface, we should instead think of all 
the different kinds of plugins we would have, and design an interface 
for the engine that would handle this kind of plugin or this kind of 
plugin, and repeat. After this process, if we find parts of the engine 
interface in common between each kind of plugin loader, then we can 
design THE plugin interface which will not be a plugin loader, but a 
PluginLoader loader :) hehe. I'm still thinking whether or not this 
added level of abstraction is that great tho...

Back to tables, tags, trees, and types. I honestly think that if the 
right metadata were available for a given dataset, you should be able to 
convert between these representations automatically, so much so that it 
should be a UI option when viewing a given dataset. I have already 
described an isomorphism between tags <=> trees (assuming a set of 
unique identifiers, and a primary tag), and I would like to remind of a 
common situation for converting between tables <=> trees, for example 
the doc hierarchy usually found in /usr/share/doc/project as compared to 
the documentation before installation, (perhaps found in 
/usr/src/project/doc). To illustrate this with some GNU utils:

ID                      F1             F2
coreutils.pdf     coreutils      doc
gawk.pdf         gawk           doc

The only way to have these accessable either by project-first or 
doc-first methods are to mirror one directory structure to another: 
/usr/share/F2/F1 and /usr/src/F1/F2 are logically the same datasets 
represented in different orders. The best visual way to represent this 
kind of dataset is in a table, as  shown above. This is not really an 
isomorphism since its really only one way, given any table, a tree-based 
structure can be constructed, but given any tree a completely different 
table-based structure might be used, and so is not unique (required for 
isomorphisms).  On a different note, I was thinking about multiple 
inheritance, and and it struck me, this is no different than allowing 
tag-sets for super-classes, and going the other way, all tag-based 
systems can be represented by inheritance of tags rather than by 
folder-enclosure. So we also have an isomorphism between tags <=> types. 
Wow.

Andrew Robbins