[tahoe-dev] Pythonic API

Randall Mason clashthebunny at gmail.com
Wed Apr 24 10:55:23 UTC 2013

Ticket [404](https://tahoe-lafs.org/trac/tahoe-lafs/ticket/404) talks about
two ways tahoe may be extensible. I'm very interested in the first case:
> The answer is you either use import to load the Tahoe code and then you
run it (precisely how, I'm not sure -- perhaps by calling startService() on

So far, I've gotten tahoe running in Kivy's event loop with modifications
to the Client class.  It is pretty much what was said, I register the
{{{Client}}} class object's {{{startService}}} method with kivy's twisted
reactor and can access the object from kivy's buttons and lists and such.
Right now, tahoe requires that it be set up with {{{tahoe.cfg}}} in a
directory before you can instantiate a client object.  A path to a pythonic
API is to make it possible to override all tahoe.cfg options in a Client
class creation.  Right now the only thing you can set is "basedir".  My
modifications allow you to point basedir to any directory and then set the
basic requirement {{{[client]introducer}}} and many of the optional things,
like {{{nickname}}} and {{{web_port}}}.

Things basically work pythonicly right now without my modifications if you
have an already configured basedir and you call things from python.  I was
able to set up the objects and then drop to an iPython shell and do things
like create directories and upload blank files.  This all is guess work and
would benefit greatly from documentation.  I essentially went in and looked
at tests that exercise different parts of tahoe and copied what was
imported, called, and passed between things.  Not being an expert on
twisted and interfaces, my experiment has stalled slightly.

Would somebody more knowledgeable than I be able to produce some
documentation on using tahoe from python?  Maybe just a walkthrough in
iPython with creating a twisted reactor, starting it, and manipulating the
Client object with helper functions to create a directories, upload some
data, read directories, and read some data.  Would the best thing be to
create a new ticket that requests this documentation and a ticket that
requests changes to the Client class so that it is fully configurable
without a preconfigured directory?

I'm interested for three reasons.  Firstly, it would be nice to have a full
fledged Android/iPhone app that would not run a web service in the
background.  All interaction being possible programmatically allows it to
be more simple (and I think may be required for Apple's app store).
Second, I would love to be able to create a fuse layer on top of tahoe like
[S3QL](http://code.google.com/p/s3ql/).  It could even just be a patch to
S3QL that would bring full file system capability to tahoe.  It could be as
complicated as using larch, a b-tree implementation in python, to create an
analog to S3QL for tahoe.  Thirdly, it's a small reason, but important.
Getting away from the WebAPI for controlling tahoe would be a security win
for me.  There are so many things about web browsers with javascript that
complicate security these days that I would feel more at ease without
Google or my aunt's hacked blog to have access to my tahoe data.  Either
way, dreaming big here.


Randall Mason
clashthebunny at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130424/59428964/attachment.html>

More information about the tahoe-dev mailing list