Add appendFile method.

[rrthomas]

Currently implemented but does nothing in REST: to try to avoid problems, it logs the data with a warning to the console.

[graphicore]

I just had a quick web search, it looks like POST is the way to go and I think it's OK to use POST even when the file to append to does not exist (fs.appendFile also creates non existant files):

from http://tools.ietf.org/html/rfc7231#section-4.3.3 see the last 2 points

POST is used for the following functions (among others): o Providing a block of data, such as the fields entered into an HTML form, to a data-handling process; o Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles; o Creating a new resource that has yet to be identified by the origin server; and o Appending data to a resource's existing representation(s).

Upon successful creation an answer of 201 CREATED is appropriate and setting the LOCATION header header to the URI of the created resource, which in our case equals to the request URI can be done but if not we are still good:

6.3.2. 201 Created The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI. ...

And when we appended to an existing file a good answer would be:

6.3.5. 204 No Content The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied. ... The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

I can do this if you prefer so.

[graphicore]

I had a short look at the fuse struct and I think it's interesting as inspiration for the future of the io api.

You are right to say we have to differentiate between our application and our use of io and the over all possible uses of io. So, forget about levels. Lets just try not to implement things in one API that are hard or impossible in the other API. append is obviously a very useful method but stuff like file locking would cause real trouble for a RESTful interface and just not doing it in metapolator is preferable, if you ask me. Also, I don't even think we have to constraint all backends that we are going to implement (for metapolator) to have all methods available, but REST and fs are really central.

[rrthomas]

@graphicore, given that the point of the I/O abstraction is to give a common API for different transports, I think your idea of implementing only things that can be implemented in "any" transport makes sense. This also chimes with my idea of making the API look like normal object access, rather than like files, as that removes the temptation to do anything "out of band".

Yes, I'd be most grateful if you could implement this method in the REST back-end.