proposal: Files API - dot return DAGNodes on Add

[daviddias]

I've been seeing a lot of users getting confused with the fact that we return DAGNodes on a files add for each file. A DAGNode contains all the information that we might would have hoped for, like the multihash and size of the tree, however, since it has a data field, users are getting confused thinking that the data of that file is on that data field, while in fact, that datafield is just one of the pieces of the whole file.

What if we changed the API to instead of returning DAGNodes, to return just an object with path, multihash and size?

[hackergrrl]

That sounds reasonable. +1.

On June 16, 2016 2:21:27 AM PDT, David Dias notifications@github.com wrote:

I've been seeing a lot of users getting confused with the fact that we
return DAGNodes on a files add for each file. A DAGNode contains all
the information that we might would have hoped for, like the multihash
and size of the tree, however, since it has a data field, users are
getting confused thinking that the data of that file is on that data
field, while in fact, that datafield is just one of the pieces of the
whole file.

What if we changed the API to instead of returning DAGNodes, to return
just an object with path, multihash and size?

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#29

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[victorb]

Yeah, sounds reasonable to me as well. For me, the hardest part is knowing how to get the hash, without knowing everything about the implementation. For example, if I'm adding a file and I want to know the hash of that file, I would have to do the following:

res[0].node.toJSON().Hash

Whereas I would expect the Hash property to sit next to the node property or possible inside. Today, even if I log one entry in the response array, there is no way to easily see the hash itself, not sure why it's hidden behind the toJSON method.

{ path: 'a-test-file',
  node:
   DAGNode {
     _cached: null,
     _encoded: null,
     data: <Buffer 08 01>,
     links: [ [Object], [Object], [Object], [Object], [Object], [Object] ] } }

[daviddias]

@victorbjelkholm the 'Hash' is generated through the multihash() call, which returns the multihash and then has to be encoded.

I kind of feel more and more that we should avoid returning the DAGNode for the Files API. once I get over with all the network stuff, I'll go back to this. If someone wants to take that charge, feel free to do so :)

[daviddias]

Once #28 is complete. Let's review the files API with this proposal

[daviddias]

Follow up here -> #56