From @whyrusleeping on Fri Jul 08 2016 22:05:03 GMT+0000 (UTC)
> Is this meant as a convenient editor for adding IPFS directory objects?
Yes, among other things
Does this have an advantage over just editing a directory in the local file system and adding that?
depends on what your usecase is, ipfs add actually uses this code under the hood, so performance should be identical
So each modification done in ipfs files is added to ipfs. Is that what the ipfs files flush command is for?
Each modification is stored unless you use the --flush=false option. If you set flush to false, it will not write intermediate objects out until you run a command on that branch with flush true, or you run ipfs files flush on the directory/object in question
I notice that entries into the files API are not pinned, should they be?
This one is tricky, and something we havent quite finished. Stuff in the files API are not currently pinned, and they should not be pinned recursively. The reason for this is because one use case we want to explicitly support is ipfs files cp /ipfs/Qm20TBDataSet /somewhere, and be able to operate on that dataset without pulling it entirely local. Towards this, we are going to implement a new pin type called ‘best effort’ that will keep what you have local, local. Until then, be wary running a gc if youre playing with the files api.
Long term, are we all going to have an IPFS ‘drive’, that our file browsers understand, where we organize the contents of IPFS?
Thats one idea 
And one i very much support