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 _______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
