[tahoe-dev] GSoC Tahoe project

[Brian Warner]

Kevin Reid <kpreid at mac.com> writes:

> To support this I imagine instrumenting the nodes with a 'current
> activity' field/stack (I'm assuming each is single-threaded/event-loop
> -- correct me?), and noting what portion of time is spent with it on
> 'network output' vs 'crypto computation' vs 'network input' vs 'disk'
> etc. Combine this with numbers of actual bits of data transferred, and
> we can hopefully reconstruct where the bottlenecks are.

Take a look at the "UploadResults" class.. it captures a lot of the
timing information about a single upload. (there are similar objects for
downloads, and for mutable-file mapupdate/retrieve/publish operations).
Most of these objects are presented in the webapi's "Recent Uploads And
Downloads" page.

There's a brief timeline display (using a Google Charts URL) on some of
those pages, meant to convey something about how long each server was
taking. It would be great to replace that with something better.

>> So, one of the first things you have to do, Kevin, is choose a GUI
>> toolkit for Python.

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

Doing it in the webapi would mean using something like PIL, which is a
python library for programmatically creating GIFs and PNGs (usually with
APIs like "draw red line from x to y"). There are probably half a dozen
such libraries.

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.

We might split the overall task up into two pieces: visualizations of
relatively static things, like how time was spent in the most recent
upload, versus more dynamic things, like real-time displays of how much
bandwidth we're using to each server. In that case, the performance of
the rendering process is more interesting for the latter half. In
addition, there might be different tradeoffs to have for each piece,
such that it might be appropriate to use an in-node web display for the
static stuff, but an external-program realtime display for the dynamic
stuff.

Anyways, I hope you'll consider the benefits that doing it through the
webapi might offer.

> The visualization itself needs primarily a general and fast *drawing*
> system. My *preference* would be for a library which offers OpenGL
> drawing, perhaps via a scene graph/retained mode interface to avoid
> having Python in the per-frame logic.

Incidentally, some of the Python+3Dgraphics libraries you might
investigate are:

 pygame
 pyglet
 soya3d

All of them provide for UI elements, as well as scenegraphs and OpenGL
stuff. pygame and pyglet, at least, seem to work pretty well across
multiple platforms.

cheers,
 -Brian