Finally the TwoWayWeb a straw man roadmap. Jon Schull

Document Sample
Finally the TwoWayWeb a straw man roadmap. Jon Schull Powered By Docstoc
					                            Finally the TwoWayWeb: a straw man roadmap.
                                         Jon Schull June 27, 2005
Overview
Tim Berners-Lee's original vision was of a two-way web.
It never happened. Here it is.
  Web pages are editable, and extensible, by many individuals simultaneously, using only their browsers.
  Changes made by anyone are visible to everyone immediately.
How we are doing it.
  Borrowing heavily from Tony Chang's webnote, we allow people to go to a URL.
  The page comes back with just enough javascript to bootstrap the rest.
        Most importantly the page polls a server once per second, reporting on changes to its own content and getting
        back reports of changes made by other browsers pointing to the same URL.
  The system is arbitrarily extensible
        New notes can be created with a single click.
        New pages get created (wikily) when we link to them.
        And new functionality can be created by adding javascript to notes. This javascript can add new functionality to
        the note, to other notes, and (in principle) to the server itself. (A sandboxed server will be required before we
        server code be entered into notes.)
      Scalability will be achieved by making every browser a potential server.

These are not trivial problems but they are all clearly solvable and the consequence is profound:

        Collaboratively and in real time, users can collaboratively develop and elaborate dynamic and persistent
        websites from any javascript-enabled web-browser even if they have no other means of editing or saving files
        locally or remotely.
Restating the goal and anticipated mechanisms
 The goal
     Using only a browser, every 2way page is modifiable and modifications are seen, in parallel, by everyone
     who views that page.

     We are making a platform from which many applications can be built (using the platform).

       Dynamically reconfigurable multi-person text-as-you-type chat where each person’s text
       aggregates in person-specific windows, alongside a transcript that visualizes both sequential
       and parallel communication.

       Real-time Wiki

       ManyToOne aggregated input (useful for classroom discussions)

       OneToMany Broadcast

       Platform for User-configurable compositing of multiple datastreams into a single multi-panelled
       page (useful for combining powerpoints, streaming video, captioning, online meetings, etc.)

       A platform for retrofitting “real-timing” other applications such as conventional webpages and
       tiddliwikis to turn them into real time collaborative shared workspaces.
Evolution
     We started with an html table with ajax-enabled editable cells

     We moved to Tony Chang’s Webnote

     Mike Axelrod added Real Time Polling (see http://social.it.rit.edu/mediawiki/index.php?title=Multichat )

     John Resig and Tristan O’Tierney simplified the Server, working toward a trivial server-install.

     Dan Bogaard is adding wysiwyg- editing

     Chris Egert is teaching elements to report changes to the poller

     Mike Axelrod will embed the server in the browser

     Thus, the two way web: a user-modifiable, peer-to-peer, distributed platform
Planned design (in progress and tentative)
    Modifications are easy because the structure of a 2way page is simple:

      Script Src=2way.js

      a poller is created onload by 2way.js

      every 2way page has at least one element for class 2way: e.g.,
         <h1 class=”2way”>
           Drag me, click to edit me, shift-drag to resize me, Alt- (or command-) click to clone me
         </h1>

    Every 2way element

      Is editable (by double-clicking the element or with a tool like platypus)

      Is resizable

      Is clonable

      Has a unique URI

      Gets itself reported by the poller
How Changes propagate (two candidate methods)

  Method 1 (presumes that elements know when they have changed)
    Onchange, every element sets Poller.Changed[MyName] =true

    Each poll, the poller
      Sends a serialization of every changed element to the server

      Sets every elements in Poller.Changed to false.

  Method 2 (requires that every element be hashed with each poll)
    Each poll, the poller hashes every element and compares the hash to a stored hash.

    For each element that has changed
      Poller updates stored hash

      Poller sends a serialization of every changed element to the server

    Method 2B would be faster but more complex: do a series of hierarchical (binary?) hashes, so that
    if a high-level hash was unchanged, we know the lower level units don’t need changing.

    (Methods 2 and 2B would work even if elements got changed via platypus or some other means.)
The server

  Stores all of those serializations (overwriting any previous versions)

  Delivers new Serializations to the Poller
The poller

  Reports new and changed elements to the server (as described above)

  Deserializes and updates new and changed elements received FROM the server.
    This requires and presumes that we can serialize 2way elements, and include their position in the
    DOM (parent, and Previous Sibling)

    This requires and presumes that we can deserialize every two way element received from the
    server insert it into the right place in the DOM
Scalability

  Scalability will come from a distributed architecture.
     Any browser can run a server, and carry his share of the load.

  Robustness and Distributedness
     But if you’re not running a server you can partake of someone else’s server (as in the current central
     server scenario).

     Every browServer that is serving puts its IP address into notes that it is disseminating.

     Every server can store the conversation it is involved with.

  Load balancing
     So clients can switch allegiance to other servers in the conversation.

     If they move toward the more responsive servers, the load will shift to the stronger servers.

     If a member drops out and someone was depending upon it’s server the someone will experience a
     drop in responsiveness and can shift allegiance to a surviving participant.
Extensability

  Elements are components from which larger elements can be built.
     Elements can include javascript and src=lines that refer to other elements (in any web page).
       In order to prevent a corrupted element from poisoning all who depend on it, we need a way of “locking” the include
       to a specific version. One way would be to build a query-responsiveness into the server that would allow client
       commands like src=whatever.url?21June2005pm1100 to retrieve a specific version of the element.url script
       (which version is preserved by the server)

     Elements can be dragged into other elements
       This may just mean that the src=whatever.url?21June2005pm1100 is automatically added to the drag-target

				
DOCUMENT INFO