[tahoe-dev] 回复: Re: hello

Zooko Wilcox-O'Hearn zooko at zooko.com
Mon Nov 5 16:10:51 UTC 2012


Dear Han Zheng:

I'm glad you are learning how to write Python code to extend the
Tahoe-LAFS gateway.


On Fri, Nov 2, 2012 at 9:29 PM, han zheng <z.han0903 at gmail.com> wrote:
> if __name__ == "__main__":
>     c = client.Client("/home/nick/.tahoe")
>     uploader = c.getServiceNamed("uploader")
>     uploadable = FileName("/home/nick/test.tar.gz",None)
>     d = uploader.upload(uploadable)
>     d.addCallback(printSuccess)
>     d.addErrback(printError)
>
>     reactor.callLater(10,reactor.stop)
>     reactor.run()
> ----------------------------------------------------------------------------
>
> When I ran "python test.py"(the file located in "/home/nick/.tahoe"), there
> was an Failure instance like this: "client gave us zero servers"
>
> Should I do some initialization work? and how?

I'm not sure, but I think the key might be that you need to invoke
"startService" on the client object:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/src/allmydata/node.py?annotate=blame&rev=26d3869076f02351a821a3e4dd7049fd234f6bb6#L287

It looks like there isn't a way for your Python code to tell *when*
the service is finished starting up. Perhaps you'll need to extend the
current code to return a Deferred from the startService method and
trigger that Deferred once it has done everything it needs to do. Then
your new code that wants to use a started-up client can attach a
callback to that Deferred to do whatever your new code wants to do
after the client is ready.


> I ran "tahoe start" before I ran "test.py"

The shell command "tahoe start" won't help! That starts a separate
operating system process in which Python runs and in that Python
interpreter, the tahoe "client.Client" object gets constructed and
started. Then when you run "python test.py", another, separate
operating system process is created with its own Python interpreter
and its own "client.Client" object. The two processes have completely
separate Python interpreters, so what Python code you run in one will
not have any direct effect on the other.


> If I only use tahoe as backup system, I think uploading a file directly to the cloud is more efficient

Hm, you know what? I was about to write that I think you're wrong —
that uploading the file by "tahoe put" through the web API will be
just as efficient as your Python code that uploads a file from within
the client. But, maybe it *will* be different. The webapi has to store
a copy of the uploaded file in temp space on disk before beginning to
upload it. The inside-the-Python-interpreter code would instead just
make a pre-pass over the file, reading all of its contents, before
beginning to upload it.

In any case, you should measure how much difference it makes in
performance. It might be a big difference, a little difference, or no
difference. Your in-the-Python-interpreter code might even be *less*
efficient than code that goes through the webapi. Measure!


Regards,

Zooko


More information about the tahoe-dev mailing list