-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Improve paths in CoreApi #4672
Improve paths in CoreApi #4672
Conversation
Responded to the TODOs here: #4666 (comment). However, all that will take a while... |
87cb6a2
to
4598c0e
Compare
f71e588
to
0ad0aed
Compare
I imported suggestions from #4666, @Stebalien can you have a look? (start from interface changes) |
core/coreapi/interface/coreapi.go
Outdated
|
||
// ResolveNode resolves the path (if not resolved already) using Unixfs | ||
// resolver, gets and returns the resolved Node | ||
ResolveNode(context.Context, Path) (ipld.Node, error) | ||
|
||
// ParsePath parses string path to a Path | ||
ParsePath(string) (Path, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really a fan of attaching helper functions to instance objects. What's the motivation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although... that could allow us to put a Resolve
method on the path object itself...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation?
We need ResolvePath
on the interface as it is quite implementation specific, I thrown the other methods here for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with ResolvePath
. However ParsePath
, IpfsPath
, and IpldPath
seem like pure helper functions.
(I don't feel that strongly, it just feels a bit funny).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I'm starting to feel more strongly about this. The core API should be as small as we can make it. Sticking helper functions into the API (especially ones like IpfsPath
and IpldPath
) will force us to keep extending the API every time we need a new helper function). Unless there's a really good reason to do this, I'd like to remove them.
@magik6k it looks like test coverage of core api is low in general. Could you work on this in future? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to make so much of our code so much cleaner.
core/coreapi/interface/path.go
Outdated
|
||
// ResolvedPath is a resolved Path | ||
type ResolvedPath interface { | ||
// Cid returns the CID referred to by path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (Cid versus Root) will need some careful documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some docs
core/coreapi/path.go
Outdated
return p.(coreiface.ResolvedPath), nil | ||
} | ||
|
||
ipath := p.(*path).path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This cast shouldn't be necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be here to get to internal ipfspath.Path
, at least for now.
I'll deduplicate logic from here and ipfspath in a separate PR, doing so in this PR would make it way bigger than it needs to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
core/coreapi/path.go
Outdated
return nil, err | ||
} | ||
|
||
resolveOnce := uio.ResolveUnixfsOnce |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we now have the namespace, we can pick the resolver based on it (possibly even create a mapping). We can do the mapping later but, for now, we should do something like:
var resolveOnce ResolveOnce
switch path.Namespace() {
case "ipfs":
resolveOnce = uio.ResolveUnixfsOnce
case "ipld":
resolveOnce = resolver.ResolveSingle
default:
return someErr
}
}
core/coreapi/path.go
Outdated
} | ||
|
||
func (p *path) Namespace() string { | ||
if len(p.path.Segments()) < 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't all paths have namespaces now? It would be nice to check this (and parse out the namespace) on initial parse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't all paths have namespaces now?
They do, ipfspath.ParsePath
guarantees that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we panic here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f95f862
to
2dd511f
Compare
I've added some more tests and fixed rest of the stuff that needed fixing |
@Stebalien @Kubuxu can you have a look at this PR, would be great to have this move (it blocks most of coreapi-related efforts) |
@whyrusleeping can we try to get this in after 0.4.16 release stuff is done? |
@magik6k Yes! Getting the other coreAPI work unblocked is high priority. Sorry for the lag |
@magik6k alright, mind rebasing this? This will be the next thing we merge |
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
be180c1
to
9d6e786
Compare
License: MIT Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
9d6e786
to
4d5a96b
Compare
done |
Improve paths in CoreApi This commit was moved from ipfs/kubo@9bad5fe
Fixes #4666
TODO:
path.Namespace() == "ipns"
or something more complex?