Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup instances of manual resolver construction #5492

Merged
merged 1 commit into from Oct 2, 2018

Conversation

magik6k
Copy link
Member

@magik6k magik6k commented Sep 19, 2018

Part of #5491

Given how messy and all-over-the-place this PR is, I'd rather keep it small. This only cleans up places which constructed their own resolver. I'll take care of the other parts, which use node.Resolver in next PR

@schomatis
Copy link
Contributor

Could you provide me some pointers about this PR that would help me review it?

@magik6k
Copy link
Member Author

magik6k commented Sep 20, 2018

The idea (mentioned in #5491) is that we want to start using the coreapi resolver basically everywhere.

The resolver was discussed in #4666 / #4672, the TL;DR is that it decides which resolver to use based on the prefix, so that /ipfs/ paths will always resolve with the unixfs resolver (handling hamt) and /ipld/ with the simple resolver (which basically uses IPLD paths). It also handles /ipns/

}

// A ReadSeekCloser implements interfaces to read, copy, seek and close.
type ReadSeekCloser interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code seems to be repeating the interfaces already defined in go-unixfs:

https://github.com/ipfs/go-unixfs/blob/master/io/dagreader.go#L22-L37

(Or maybe it's the other way around and UnixFS is duplicating these ones, either way, is it possible for one to reference the other?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That will be doable once the coreapi interface is extracted, which I hope will happen fairly soon - for progress see #4498 (I want to have pubsub/swarm/unixfs done before extracting the interface)

License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
@magik6k magik6k added the topic/core-api Topic core-api label Oct 2, 2018
@magik6k magik6k requested a review from schomatis October 2, 2018 16:47
@Stebalien Stebalien merged commit 49bb9fb into master Oct 2, 2018
@ghost ghost removed the status/in-progress In progress label Oct 2, 2018
@Stebalien Stebalien deleted the feat/unify-resolving branch October 2, 2018 17:09
@magik6k magik6k mentioned this pull request Jan 15, 2019
51 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/core-api Topic core-api
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants