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

Comment (by davidsarah):

 IRC conversation, edited for formatting:

 davidsarah: did you see my suggestion on #1732 ?

 warner: yeah

 warner: I'm uncertain about changing t=rename. Basically t=rename
 currently addresses a directory, and tells it to do something to itself.
 It's a single atomic operation (well, as atomic as changing any mutable
 file)

 davidsarah: well, the operation we want is a strict generalization of
 rename

 warner: whereas t=move addresses one directory and tells it to talk to a
 (possibly different) directory

 warner: from a filesystem point of view, yeah

 davidsarah: but only possibly different

 warner: but in terms of dirnodes, that generalization would increase the
 number of actors from one to two

 davidsarah: if the destination directory for t=move is the same as the
 source, then it should be atomic (from the filesystem point of view)

 warner: true

 davidsarah: so the complexity is still there

 warner: yeah. I guess I think of a lot of the webapi in terms of speaking
 to a specific node and telling it to do something

 davidsarah: basically the only difference between t=rename in my
 suggestion and t=move in https://tahoe-lafs.org/trac/tahoe-
 lafs/ticket/1732#comment:30 is the defaults for to_dir and to_name. I.e.
 to_dir defaults to the source dir, and to_name defaults to from_name

 warner: from the outside, yeah

 davidsarah: I'm all about eliminating redundancy :-)

 warner: but the current t=rename is quasi-atomic (there's no way to wind
 up with multiple copies of the child), and that would change it to be
 sometimes non-atomic (if interrupted, it might add to the target but not
 remove from the original)

 warner: I dunno

 davidsarah: [It would be non-atomic] only if to_dir is provided

 warner: I guess we could argue that having a t=move with the proposed
 syntax means it'd be cleaner to modify t=rename instead

 davidsarah: besides, there was a suggestion to deprecate t=rename if we
 added t=move

 warner: hm. ok, so I think "rename" shouldn't be used to move something
 long distances, whereas "move" is a fine verb for that. And I guess my
 attitude suggests that, if we only have one command, then it should be
 "move"

 davidsarah: hmm. I don't place much significance on the operation name

 warner: I dunno. [...] let's pester zooko to think about this too

 davidsarah: well, we don't have the option of adding move and immediately
 removing rename... if we want to retain backward compatibility

 warner: yeah, true. So if we keep rename around, then it suggests that
 "move" should be something different

 davidsarah: I think we need Zooko as a casting vote :-) (it is actually
 quite useful having 3 of us deciding these things)

 davidsarah: here's another advantage of my suggestion: the existing tests
 for t=rename will test the same-directory case, and so the new tests only
 need to cover the different-directory case

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