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