[tahoe-dev] GSoC Tahoe project

[Kevin Reid]

[Resent to tahoe-dev with permission.]

On Apr 9, 2009, at 0:27, zooko wrote:

> Kevin:
>
> Sorry for the delay.  I would like to be your primary mentor for  
> this project.  Is that acceptable to you?

Yes, of course. (I don't know enough of your vs others' technical  
skills to know whether this is an appropriate fit.)

> I've been doing something I call "dogfood tasting" today -- using  
> Tahoe and writing up my experiences on the tahoe-dev mailing list.   
> This process keeps showing me new ways that I wish for more  
> visualization into Tahoe.  For example, right now I'm looking at a  
> great big chart of numbers (attached) and wishing to know how much  
> each of 10 servers contributed to the speed of a multi-minute  
> download.  Also, I wish to be able to show the resulting fact to  
> other people so that they will "get it" in a single moment's  
> glance.  Whatever "it" is.

Yes. First sketch: Display client computer, web gateway (wapi/Tahoe- 
client), and storage servers in a graph. Depict the amount/rate of  
data transferred as the thickness of the line between them. If one  
side is spending time waiting for data/waiting for space to send data  
rather than doing disk IO/crypto, its side of the line is wider.

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.

> So, one of the first things you have to do, Kevin, is choose a GUI  
> toolkit for Python.  This turns out to be non-trivial as there seem  
> to be many mature, actively developed, featureful GUI toolkits.   
> Plus many more that are dead, licence-incompatible, etc..  I've  
> attempted to do a first pass for you and omit the dozens of useless  
> ones.  Here's what I have left:

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.

Secondarily, there will probably be a few text/widget windows for more- 
details and/or interactive functions.

I don't have time right now for a thorough review of libraries.

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