Reuse allowed under an X11 "BSD Revised" type license.
TSOX stands for "The Skills of Xanadu", for a 1956 short story by Theodore Sturgeon, which can be found in his book, "The Golden Helix".
The current code can be downloaded here as a ZIP archive.
It is in Python (1.5.2) using the wxPython/wxWindows windowing system.
These are available at:
Python: http://www.python.org/1.5/
wxPython: http://alldunn.com/wxPython/
It has only been tested under Windows NT 40 SP 3.
Use the buttons below the HTML panel (this one if your viewing this in TSOX) to load an HTML file for viewing.
Use the hierarchical list to the left to browse around files located in subdirectories of the directory above the one you are running theis Python script from.
The next step is to have the hierarchical list viewing a repository of versions of files/data. Then the HTML viewer could also view the contents of archived nodes (instead of just displaying the node name as at present).
More details from a previous email on this to the Bootstrap mailing list:
Subject: [unrev-II] Hierarchical version tool (was: Moving beyond the web...) Date: Thu, 04 May 2000 09:32:24 -0400 From: Paul Fernhout <pdfernhout@kurtz-fernhout.com> Reply-To: unrev-II@egroups.com Organization: Kurtz-Fernhout Software To: unrev-II@egroups.com References: 1 Jon Winters wrote: > > In addition to everything else we have been beating about I would like to > suggest that we consider a move away from a centralized server and a move > in the direction of "every client is a server too" The short story "The Skills of Xanadu" by Theodore Sturgeon (available in his book The Golden Helix) written in 1956 has a similar model for information sharing. People wear crystals (sort of wearable computers with wireless connections) which can communicate what the owner knows to everyone else, so when you want a skill, you can draw on it from the person who knows it best. I've been thinking about something like this for OSCOMAK http://www.kurtz-fernhout.com/oscomak/index.htm inspired in part from my work with IBM/OTI's ENVY software repository called ENVY/Developer. http://www.oti.com/briefs/ed/edbrief5i.htm IBM/OTI's ENVY allows multiple developers to work on object oriented code, tracking fine grained changes to every function or method, as well as changes to classes, and applications. These changes are versioned into things which can be compared, exported, and imported. For example, I can make a version of a class that includes specific versions of certain functions. I can then make a version of an application that includes versions of specific classes. So, this is a somewhat hierarchical idea of versioning. One can also enforce prerequisites -- that is, to load a version of one application, I need to first have loaded a compatible version of another application (where compatibility usually means a certain version number or later.) I really like the discussion of an email based system. I agree that Slashdot type forums have drawbacks. One of the biggest is getting started. As one can see from my Zope/Squishdot experiment server, it is hard to get people involved with it if it isn't an interesting enough place to visit frequently because people aren't involved with it (a catch 22). Email lists can be interesting with just a handful of people on them, and so "bootstrap" better than Slashdot style efforts. I've also been thinking along the lines of a system that works like email, or perhaps is an actual email client (like Eudora or the Netscape email part). Here is what I have been thinking of (using ideas similar to those in ENVY). This is simplified somewhat for presentation here. You use a system with three panes -- one for browsing/searching (B), one for display (D), and one for composition(C), typically laid out as: BB DDDD BB DDDD BB ---- BB CCCC BB CCCC One pane (B) is a hierarchical list of all content and all versions (a browser). It act as a cache of web content, as well as content from email threads. You can also export any item (and its sub-items) into a MIME-style email http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html or a file. Similarly, when you receive email or import a file it changes this panel. You can click on any element in this tree and it shows up in the display pane. The display pane (D) is an HTML/MIME type viewer. It shows the specific page or email you are looking at. A more sophisticated version of this pane lets you look at multiple things at once in a draw/windowing type environment. Any item in this pane can be copied to the composition pane. Note that display and composition are separated so you can view an existing item while creating something derived from it. Also, when using this pane as a HTML web browser, when you click on a link, the contents gets added to your cache, so you can view it off-line later The composition pane (C) is an general purpose editor, capable of composing text, HTML, or other supported formats (maybe drawing). It has a line at the top to define a hierarchical URL. When you are satisfied with something you are editing, you click a version button, and a version of it appears in the hierarchical list browser pane, according to the URL. (Note, that no "directories" as such are needed -- so you can make any path you want.) If you version something in the composition panel multiple times, the browser can reflects this with a number showing the number of versions of an item. You can the select a specific version you want to look at when you drag something into the viewer panel. Using an ENVY style versioning system, hierarchical items can be versioned or "open". Versioned items are specifically linked forever to specific versions of things they contain. Open editions allow the versions of what they contain to change, until such time as the open container is versioned. Only versioned components can be exported or mailed. These export files are tiny repositories that contain one approrpiate versions of every thing in the tree that was exported. So, for example of use: I compose a note and version is, with a URL like: //Paul's Notes/Note0001 And contents: "Just testing a first note" I then email that note to individuals or a mailing list (mailing list = rebroadcasting server). You can then make a new version of that note and mail it around. Then everyone has two versions of the note (each item contains a signature of who authored it and the date and time). Or, you could make a reply to the note, with a URL like: //Paul's Notes/Note0001/Reply0001 And contents: "Just testing a reply to the first note" To which I could make a reply: //Paul's Notes/Note0001/Reply0001/Reply0001 with contents: "Just testing a reply to a reply" and maybe also a: //Paul's Notes/Note0001/Reply0001/Reply0002 with contents: "Just testing a second reply to a reply" There are various issues to be resolved in such a scheme, like the format of the hierarchical replies. A more plausible system might have a series of nodes like: //Bootstrap Notes/Lets make a DKR Contents: "We should make an open source DKR along the lines Doug proposes..." //Bootstrap Notes/Lets make a DKR/Yes I agree //Bootstrap Notes/Lets make a DKR/But look at this //Bootstrap Notes/Lets make a DKR/But look at this/Wow that's cool //Bootstrap Notes/Lets make a DKR/Let's introduce ourselves //Bootstrap Notes/Lets make a DKR/Let's introduce ourselves/Paul Fernhout //Bootstrap Notes/Lets make a DKR/Let's introduce ourselves/Eric Armstrong //Bootstrap Notes/Lets make a DKR/Let's introduce ourselves/Paul Fernhout[1.1 typo fixed] //Bootstrap Notes/Lets make a DKR/Let's introduce ourselves/Paul Fernhout[1.2 more background] (The last two are new versions of the "Paul Fernhout" introduction as I or someone else revises it...) //Bootstrap Notes/Lets make a DKR/Yes I agree[1.1 Version 1 on May 4, 2000 called "Just starting..."] //Bootstrap Notes/Lets make a DKR/Yes I agree[open] (Here a version was made called "Just starting..." of this email discussion. This means users could retrieve that specific version in the future, so see a snapshot at that point in time. Of course, multiple different open editions can be created so that for source code, different people can work on the same thing at once. Then later, special tools allow versions to be "merged".) Note that someone could start their own private discussion, and just not share those nodes with the list, by not exporting them. //Bootstrap Notes Private/What do I really want to do? //Bootstrap Notes/Lets make a DKR/Private/Too many long postings by Paul? One can also do this with content related to the web, by using web-published URLs: //www.microsoft.com/[1.0 Jan 1, 2000 -- Cached] <<-- the official site cached //www.microsoft.com/[2.0 April 1, 2000 -- April Fools] <<-- a lampoon of the Microsoft home page //www.bootstrap.org/[1.0 May 3, 2000 -- Cached] <<-- the official version cached from the site //www.bootstrap.org/[1.1 May 4, 2000 -- Ideas] <<-- suggested new version, only sent to some //www.bootstrap.org/[1.1.1 May 5, 2000 -- More Ideas] <<-- revision of previous revision You can see this could combine the functionality of file system, source code repository, web server, and email client. It also allows support for peer or server based file distribution. A range of export/import options would allow one to slurp C++ or Java or Python source into this system, and then burp it out again on demand, supporting activities like tracking every change you make to a Python function during development. By integrating Python or Squeak into the System, one coudl use this as a totally integrated development environment with source code control, documentation, and bug tracking. Example: //Hierarchical version tool/Version 1/Code/Editor Class/displayFunction() //Hierarchical version tool/Version 1/Code/Editor Class/eventLoop() //Hierarchical version tool/Version 1/Code/Hierarchical List Class/initialize() //Hierarchical version tool/Version 1/Code/Hierarchical List Class/displayFunction() //Hierarchical version tool/Version 1/User Documentation //Hierarchical version tool/Version 1/User Documentation/Introduction //Hierarchical version tool/Version 1/User Documentation/Tutorial[1.0 First try] //Hierarchical version tool/Version 1/User Documentation/Tutorial[1.1 Improved by Eric] //Hierarchical version tool/Version 1/User Documentation/Tutorial[1.2 Jon's Comments] If you wanted to, you can easily export the entire bootstrap discussion (from amidst all the other stuff you have) and mail or FTP it to someone as a unit. There are many issues to be resolved, and a deep issue of naming and namespaces I am wrestling with, but this is the core of the concept. [Also, a more complex system involves webs not hierarchies, but that's harder to explain...] Something like this hierarchy version could be as a first cut implemented fairly quickly (a person-month if it was also a reliable email client?) using Python and wxWindows. There are some efficiency issues -- for example the hierarchical list should be two panes, with the first being a list of top level domains to reduce the demand on the list widget... Anyway, got to run... Still paying off the last open source project :-) -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com