[tahoe-dev] GSoC Tahoe project

[Kevin Reid]

On Apr 11, 2009, at 22:02, zooko wrote:
> Brian pointed out some important tradeoffs:
>
> On Apr 11, 2009, at 18:22 PM, Brian Warner wrote:
>
>> I'd like to lobby for including this sort of functionality in the
>> webapi, instead of focussing on a GUI toolkit, since that would:
>>
>> 1) make it a part of Tahoe, specifically part of the Tahoe client
>> node, instead of requiring users to run some external program
>>
>> 2) make it available to a wider audience, instead of just those
>> who can install OpenGL/gtk/wx/etc
> ...
>> This, of course, is a severe tradeoff. The biggest downsides would
>> be giving up a number of good GUI toolkits, losing some flashy
>> animation features, and performance.
>
> I'd prefer the other side of this trade-off, because I imagine that
> animation features might turn out to be not just "flash", i.e. not
> just displaying the same information in a prettier way, but could
> actually create ways of seeing Tahoe that are impossible with the
> more limited alternative.
>
> As a third alternative, maybe Kevin would like to try newfangled web
> animation techniques such as SVG animation or the Canvas tag.

My first reaction was "SVG animation is not well-supported" but  
perhaps you actually mean animation-via-JavaScript, not SVG animation  
elements -- since we're animating based on incoming data and so we  
need scripting anyway, pure SVG animation isn't particularly relevant.

<canvas> offends my sense of web architecture (because it is only  
useful with JavaScript, rather than merely animatable-by-).

> I would support any of these three approaches, and will leave it up
> to Kevin if he has a strong preference.


I saw animation, or rather live updating, as being a fundamental part  
of the visualization.

However, it occurs to me that a graphical-but-static version of the  
current status is still useful -- and we can perhaps *augment* that  
with live data and JS.

I have no experience, however, with receiving data inside JS-on-a-web- 
page, nor with   the quirks (that I assume exist) of modern browser  
SVG support.


All that said, here's a particularly Clever idea:

The data and updates for the visualization are represented as a  
JavaScript data structure. There is a JavaScript program which can  
create or update/animate a SVG DOM.

When the visualization is requested from a Tahoe client node (wui  
server), it *executes the JavaScript program* and returns the  
resulting SVG or SVG-in-HTML document. (Note: Requires a JS  
implementation on the server. Is there one in Python?)

The document includes that same JS program, set up so that it will  
fetch updates from the server and animate the SVG appropriately.

This way, we get a useful static view, the good old "javascript  
optional", animation, *and* no duplication of client vs. server logic.

( Hey wait, is this "mobile code"? :)


Now, the advantages of a custom client + OpenGL rather than all this  
web-tech:
   * probably fitting more detail/smoother animation on the screen
   * 3D space, which may or may not be useful
   * easier to get rapid-fire updates because you're not limited to  
polling by the client

I think we need to decide more of what the visualization should  
consist of before we can tell how much graphics power we need.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>