Fitting web apis into a filesystem metaphor isn't always straightforward. For instance, it is common to POST into a container URI (which we represent as a directory) and have no control over the name or id of the object which is created. This is the case with Facebook posts.
echo "foo" > /facebook/me/posts
would imply overwriting the posts directory, which is not allowed (either on pigshell or on unix)
OTOH, asking the user to do a
echo foo >/facebook/me/posts/post-11oct2014
sets up the expectation that the post will be named that way, when it will most likely be a long numeric id. Thus, the trailing slash. Not perfect, but the best compromise I could think of.
echo "Testing status update" >> /facebook/me/posts
I think appending content to a file path (with or without the trailing slash) is clearer than the analogy of a truncating write to a directory path (where the trailing slash is required).
The current model seems similar to the REST interpretation of CRUD, where > equates to 'create' and >> to 'update', and creating a resource is done at the collection URL. Nothing wrong with this, but it seems slightly unintuitive to me.
My suggested mapping would be:
>/facebook/me/posts - Unsupported (or delete all posts, and make a new one)
>>/facebook/me/posts - Add a new facebook post
>/facebook/me/posts/long_numeric_id - Update post (truncate)
>>/facebook/me/posts/long_numeric_id - Update post (append)
In this case, both > and >> are context dependent, but more flexible. Would this strategy mesh well with the rest of the implementation?
Also, nice work! The project reminds me of Plan 9's /net.
