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 <[email protected]> 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 _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
