Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

proposal: Files API - dot return DAGNodes on Add #29

Closed
daviddias opened this issue Jun 16, 2016 · 5 comments
Closed

proposal: Files API - dot return DAGNodes on Add #29

daviddias opened this issue Jun 16, 2016 · 5 comments

Comments

@daviddias
Copy link
Contributor

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
Copy link
Contributor

That sounds reasonable. +1.

On June 16, 2016 2:21:27 AM PDT, David Dias [email protected] 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
Copy link
Contributor

victorb commented Jun 21, 2016

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@daviddias
Copy link
Contributor Author

Follow up here -> #56

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants