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

Comment (by warner):

 I mentioned to zooko this morning that I don't think I'm picky about this
 API, and am happy go along with whatever everyone else likes. But then I
 thought of two constraints that I think are important:

 * don't remove an existing API (so `t=rename` must stick around)
 * don't add parameters to an existing API that can't be discovered by
 callers, since our webapi practice is to ignore arguments we don't
 recognize

 The latter constraint precludes adding some new argument to `t=rename`
 that would change behavior, because then a new client (who knows about the
 new argument) who submits such a request to an older gateway (who ignores
 the new argument) will get a very different behavior than they were
 expecting. It's the same reason that python functions reject unrecognized
 keyword-arguments: the use of kwargs allows new callees to add new kwargs
 over time, but still get a clear error when a new caller calls an older
 callee, instead of silently ignoring the new arg and doing something
 completely different.

 So I guess that means I *am* picky about it, and I'm voting for a new
 `t=move`. :)

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