[unrev-II] Hierarchical version tool (was: Moving beyond the web...)

From: Paul Fernhout (pdfernhout@kurtz-fernhout.com)
Date: Thu May 04 2000 - 06:32:24 PDT

  • Next message: Jack Park: "Re: [unrev-II] Moving beyond the web..."

    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

    ------------------------------------------------------------------------
    You have a voice mail message waiting for you at iHello.com:
    http://click.egroups.com/1/3555/3/_/444287/_/957446966/
    ------------------------------------------------------------------------

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Thu May 04 2000 - 06:37:11 PDT