ipldResolver API as pullStreams about js-ipld HOT 6 CLOSED

@diasdavid just to be clear on this, I'd be replacing the existing get method? Trying to get a sense of what other projects I'd want to look at/ patch if this is the case.

from js-ipld.

here are the events i used to make the ipld-resolver-viz
7a012d0

from js-ipld.

Making get return pull-stream sounds like a good idea to me, it matches ipfs.get/ipfs.files.get and prepares the API for the IPLD selector in the future.

I want to keep the API as simple as possible and let any extra porcelain in users land so that we do not increase the size of the codebase (=== tests, maintenance and bundle sizes) until it is completely obvious that it is a really good nice to have.

Following ipfs-inactive/interface-js-ipfs-core#126 (comment), I propose two API changes.

a) add an option to the .get options object to just return the final result (by default it should return all the touched objects)

b) expose two API calls, one that it is .get that returns an array with all the nodes touched and another one that it is .getPullStream that does the same but returns all the nodes touched in a pull-stream

As for the porcelain such as createSpyStream, you can in your codebase create a proxy for .get calls that keeps track of all objects traversed and returns on the SpyStream or you can monkey patch the IPFS node when to create it in your code.

from js-ipld.

With the Awesome Endeavour: Async Iterators we want to move away from pull streams. There's also an upcoming API review of all the IPLD stuff, so it doesn't make sense to spend more time on this for now.

from js-ipld.

from js-ipld.

We son't use pull-streams anymore, hence closing this issue.

from js-ipld.