[tahoe-dev] remove the localfile feature from web API?

[Brian Warner]

> It seems like the localfile hack in the web API raises some issues  
> and it isn't strictly required -- it is a performance optimization.

I've got mixed feelings on this one. Sooner or later we're going to 
build a local web ui around this thing, all javascripty and AJAXy and 
shiny (and annoying to people like me who leave javascript turned off, 
but that's just a personal issue :). When we do, the only way to allow 
that javascript to efficiently put lots of data into the mesh is to use 
localfile=.. anything running over pure POST is going to require the 
user to deal with a dialog box per file.

Of course, there are other problems with a pure-POST javascript client, 
like not being able to view the local filesystem. We may have to add 
features to the backend to enable a local javascript client to see the 
local disk, to make this client behave more like a native-code program. 
So localfile= is necessary but not sufficient for the local web client.

Are there any problems with the current implementation of localfile=? If 
it complicated the code significantly, or affected performance, then I'd 
be more in favor of the "we don't need it yet" argument for removing it. 
But if it works, and has tests, and is documented, and isn't 
particularly confusing to the user or the developer, and we know we'll 
need something like it in the future, why remove it? Not needing it for 
the CLI client is a good argument for not having implemented it in the 
first place, but that's a sunk cost at this point.

Now, one argument I *can* think of for removing it is that the security 
model it encourages (by not yet offering any sort of password or HTTP 
authentication) is that anyone who is running a program on your machine 
gets to manipulate your local filesystem as well as the vdrive. On the 
other hand the node admin can simply just not enable the webapi port, 
and/or we could easily add another configuration switch that enabled 
localfile= independently from the webapi port.

> As per oral discussion with Brian, Rob and Peter (at the Meat On A  
> Stick restaurant)

I believe a lot of that discussion (and most of the issues you referred 
to earlier w.r.t. localfile=) went down into a rabbit hole about how to 
safely determine whether the two ends of the HTTP connection were in the 
same administrative domain, and thus whether or not localfile= should be 
enabled, and thus whether the CLI client should use localfile= or fall 
back to PUTs. I'm now thinking that the CLI client should never use 
localfile=. Reason 1: we know that we must have PUT support anyways (as 
a fallback), so in this case localfile= would purely be an optimization. 
2: for a local program that has full access to the filesystem, we don't 
have to worry about the javascript access limitations imposing a UI 
burden on the user (one chooser dialog per file), so the only overhead 
of PUT vs localfile= is streaming data through a localhost socket, which 
isn't very significant. 3: it removes the concerns about how the CLI 
client should decide whether to use localfile= or PUT.


So, my thoughts are that localfile= should be left in place, and the CLI 
client should use PUT and GET exclusively.

thanks,
  -Brian