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
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
