Hacker News new | ask | show | jobs
by tubelite 4277 days ago
That should be

  echo "Testing status update" > /facebook/me/posts/
I tried it and it WorksForMe (TM)

That said, two caveats:

- The FB filesystem hasn't been worked on in 1+ year.

- AFAIK v2 of the graph API will become mandatory sometime next year and does not allow apps to get lists of friends. Friend list returns only friends who also use the same app... which is pretty disappointing.
1 comments
daveloyall 4277 days ago
Trailing slash?
link
tubelite 4277 days ago
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.
link
pb2au 4277 days ago
The great-grandparent suggested:

  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.

link