[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:  warner
         Type:  enhancement    |     Status:  assigned
     Priority:  major          |  Milestone:  1.10.0
    Component:  code-          |    Version:  1.9.1
  frontend-web                 |   Keywords:  forward-compatibility blocker
   Resolution:                 |
Launchpad Bug:                 |
-------------------------------+-------------------------------------------

Comment (by zooko):

 Replying to [comment:2 davidsarah]:
 >
 > Should {{{to_dircap}}} accept a path after the dircap? Note that
 supporting that would allow changing {{{tahoe mv}}} to use this API, which
 is a prerequisite to fixing #943 in the way proposed in
 ticket:943#comment:4 (since that fix depends on knowing the path that was
 used in the {{{tahoe mv}}} command to specify the destination). If it does
 accept a path then it should be called something other than
 {{{to_dircap}}}.

 There this thing that we use a lot in the WUI/WAPI: a dircap optionally
 followed by a list of childnames. The list of childnames is clearly a unix
 (relative) path. But there's no word for "dircap+relpath". I think we need
 to coin a word for it. I can't think of anything clever and clear, so how
 about something awkward and explicit and clear, like "dircappluspath"?

 Hm, or actually I think we can extend the vocabulary of unix here. Unix
 already has "absolute paths" and "relative paths". How about if we call
 these things "rooted paths"?

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