[tahoe-dev] tahoe web content-renderers

[Brian Warner]

On 9/24/11 4:58 PM, Greg Troxel wrote:
> 
> To me, this seems like taking random other functionality that you want
> and sticking it into a file system because file systems store content.

Yeah, that's fair.

> The way to look at the graph of the
> x-application/tahoe-download-timeline-json should be independent of
> where that came from - whether it's in tahoe, in a regular file, or
> attached to mail.

Sure, but how do I give you the code that can render that new format? Do
I first need to convince your OS vendor to include support for my new
fancy timeline scheme and wait for you to upgrade? This is a general
problem with getting new formats adopted, of course.. think of how an
HDR image format wants to be displayed with a brightness control, or how
a spherical panorama (anyone remember QTVR files?) image needs panning
controls and cannot be correctly rendered with a normal rectangular 2-D
image format.

If I could hand you my own tool to render a new format, and if you could
run it safely in some trusted environment, then we could take advantage
of new formats sooner.

> Why should the WUI support this any more than any of the other 100
> Content-Types: that a file could have?

I guess I'm thinking of the WUI and the browser acting together as the
user's agent (since ideally you're running your own local tahoe client
anyways). The browser currently knows how to render a bunch of popular
data formats (HTML/JPEG/etc), but no more (unless you install a plugin
that you must then trust with everything). The WUI could extend that to
new formats, using HTML+Caja+<script> as the output target, and
basically be an environment for renderer plugins (written in confined
JS) that *don't* get your whole account authority.

Of course, given that Jetpack is my day job, maybe I should be
investigating how to accomplish this same sort of safe-renderer-plugin
scheme in the browser itself, instead of thinking of tahoe as
pre-processing frontend.

One motivation I've noticed: the JSON timeline data for the slow
downloads that we're investigating here take about 10 minutes to build.
But I'm constantly making small changes to the d3.js-based renderer, and
I'd like to be able to show a "rendering" (which needs zoom/pan
interaction to be useful) to other people. So it makes sense to me to
split those two pieces up. And that prompts the question of where each
bit lives, which makes me think of how to use tahoe as the delivery
vehicle.

cheers,
 -Brian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110924/403a83f0/attachment.pgp>