-
Notifications
You must be signed in to change notification settings - Fork 124
proposal: Files API - dot return DAGNodes on Add #29
Comments
That sounds reasonable. +1. On June 16, 2016 2:21:27 AM PDT, David Dias [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
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 { path: 'a-test-file',
node:
DAGNode {
_cached: null,
_encoded: null,
data: <Buffer 08 01>,
links: [ [Object], [Object], [Object], [Object], [Object], [Object] ] } } |
@victorbjelkholm the 'Hash' is generated through the 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 :) |
Once #28 is complete. Let's review the files API with this proposal |
Follow up here -> #56 |
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?
The text was updated successfully, but these errors were encountered: