This is the very first version of TSOX.

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