On Mon, 9 Feb 2009 15:19:08 -0700 (MST) Shawn Willden <[email protected]> wrote:
> Mon Feb 9 15:15:20 MST 2009 Shawn Willden <[email protected]> > * Allow client-specified keys Cool! Some thoughts: Take a look at the first comment in #320 for our current ideas about the webapi syntax for user-specified keys. Basically key=CHK, or key=random, or key=pp4fhu5o2eaft7zk7gmicmylpa (base32), or key=ee190f82b19632aff99718534ed89679 (hexidecimal). But if you only felt like implementing the base32 one, I'd be ok with that. It might also be a good idea to consider a type indicator, like key=base32-pp4fhu5o2eaft7zk7gmicmylpa so future extensions might be cleaner. Passing the key through the Uploadable object is exactly right. Your test_PUT_NEWFILEURL_specified_key uses base62, but your test_POST_upload_specified_key uses base32. I'd prefer to use base32 for everything: note that base62 is currently unused in the codebase (we added it early in anticipation new+shorter ECDSA-based mutable file caps). Please add a note to docs/frontends/webapi.txt (to the PUT and POST sections that deal with new-file upload) to indicate the new functionality. Please add a test (to test_web) to ensure that PUT /uri (i.e. uploading an unlinked file) also accepts the key= argument. We need a test to confirm that upload actually uses the key you requested, by asserting the returned filecap starts with URI:CHK:$MYKEY: . test_upload.GoodServer is the place for that, copy test_data_large into a new test_provided_key() and have it examine the returned URI. We also need a test to confirm that a webapi request actually uses the key you requested. The test_web suite is insufficient for this, because it fakes the upload process, so add a routine to test_system.SystemTest._test_web, around like 1170 (right after the first self.PUT/self.GET pair). Confirm that the tests work by temporarily making your get_key_arg() function always return None: that should cause the tests to fail. thanks! -Brian #320 add streaming upload to HTTP interface: http://allmydata.org/trac/tahoe/ticket/320 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
