[tahoe-lafs-trac-stream] [tahoe-lafs] #1732: consider changes to webapi "Move" API before release

[tahoe-lafs]

#1732: consider changes to webapi "Move" API before release
-------------------------------+-------------------------------------------
     Reporter:  warner         |      Owner:
         Type:  enhancement    |     Status:  new
     Priority:  major          |  Milestone:  1.10.0
    Component:  code-          |    Version:  1.9.1
  frontend-web                 |   Keywords:  forward-compatibility blocker
   Resolution:                 |
Launchpad Bug:                 |
-------------------------------+-------------------------------------------
Changes (by zooko):

 * keywords:  forward-compatibility => forward-compatibility blocker


Old description:

> I just finished reviewing and landing #1579, and it looks nice. One thing
> we should probably consider though, before committing to the API, is
> whether we're happy with the split "subdirname-vs-dircap" API. In the
> current code, you can either move a child to a subdir by name:
>
> {{{
> POST /uri/$DIRCAP?t=move&from_name=OLD&to_dir=SUBDIRNAME&target_type=name
> }}}
>
> or to a (possibly unrelated) subdir by its dircap:
> {{{
> POST /uri/$DIRCAP?t=move&from_name=OLD&to_dir=NEWDIRCAP&target_type=uri
> }}}
>
> That feels a bit weird. I'm kind of thinking that we should accept
> {{{to_dirname=}}} or {{{to_dircap=}}} (and throw an error if you provide
> both), instead of switching the interpretation of {{{to_dir=}}} according
> to the presence of that {{{target_type=}}} argument.
>
> thoughts? note this is a blocker for 1.10 (or whatever release is next
> done on trunk), since we don't want to wind up supporting the wrong API
> forever.

New description:

 I just finished reviewing and landing #1579, and it looks nice. One thing
 we should probably consider though, before committing to the API, is
 whether we're happy with the split "subdirname-vs-dircap" API. In the
 current code, you can either move a child to a subdir by name:

 {{{
 POST /uri/$DIRCAP?t=move&from_name=OLD&to_dir=SUBDIRNAME&target_type=name
 }}}

 or to a (possibly unrelated) subdir by its dircap:
 {{{
 POST /uri/$DIRCAP?t=move&from_name=OLD&to_dir=NEWDIRCAP&target_type=uri
 }}}

 That feels a bit weird. I'm kind of thinking that we should accept
 {{{to_dirname=}}} or {{{to_dircap=}}} (and throw an error if you provide
 both), instead of switching the interpretation of {{{to_dir=}}} according
 to the presence of that {{{target_type=}}} argument.

 thoughts? note this is a blocker for 1.10 (or whatever release is next
 done on trunk), since we don't want to wind up supporting the wrong API
 forever.

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1732#comment:8>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage