[tahoe-dev] tahoe web content-renderers

[Brian Warner]

On 9/23/11 6:33 PM, Zooko O'Whielacronx wrote:
> Could you provide us with the New Visualizer display of a small-K
> immutable download and of a large-K immutable download so that we can
> compare the two?

Hm, that's an interesting question. I could provide a screen capture of
such a display, and if you were lucky, I might have zoomed it in to a
useful region of interest. But since it's really a zoomable/pannable
interactive display, the real way to hand you such a display would be to
give you the JSON dataset and the javascript program to render it.

Which makes me think of the "tahoe web-app" idea I've pondered in the
past, and whether it might be interesting to have content-renderers
built in to tahoe. Imagine this:

 * I capture a trace of one particular download, and grab the JSON data
   that represents all the timeline events

 * then I store the JSON data in a tahoe grid somewhere with a
   particular filename, or maybe some "content-type" metadata that says
   something like "x-application/tahoe-download-timeline-json"

 * your tahoe client recognizes that content-type and has a JS renderer
   program for it (there'd be a built-in table mapping content-type to
   the filecap of a JS renderer program, along with some related static
   resources like d3.js and jquery.js, maybe some extra .html or .css
   files)

 * the WUI directory listing would have a "View" button next to (or
   maybe in place of) the normal filename link.

 * when pressed, a page is served that contains the JS renderer program
   and gives it a URL that points at the data it's supposed to render
   (maybe via a #fragment and XHR, or by gluing program fragments
   together)

 * in the beginning, you'd want that table of renderers to be pretty
   static and tightly controlled, because any program in that table gets
   control over your browser environment (scoped to the same-origin as
   your webapi gateway: including authority over the History API and
   scripting other frames from the same gateway, allowing the program to
   steal caps). In the future, when we get caja, we can reduce the
   authority such programs are given, and then safely let files contain
   metadata that points to a renderer of their own choosing.

You might view this as a variant/generalization of tiddly-on-tahoe
(which stores both data and renderer program in the same file). Instead,
you could store the blog/wiki data in a separate file, and give the code
a readcap (for public rendering) or a writecap (for owner editing).

intrigued,
 -Brian