-
Notifications
You must be signed in to change notification settings - Fork 6
WIP: Changes needed for --cid-base option in go-ipfs.
#8
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
Conversation
5965279 to
0a69ed0
Compare
This is more to the point and will also allow the use of apicid.Hash as keys is JSON objects.
abff5cc to
3d173cb
Compare
3d173cb to
e6e4bdc
Compare
e6e4bdc to
329c831
Compare
magik6k
left a comment
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.
First pass, need to read go-ipfs side first to get the idea behind some of this more.
|
|
||
| // apicid.Hash is a type to respesnt a CID in the API which marshals | ||
| // as a string | ||
| type Hash struct { |
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.
Why not just type Hash string?
| @@ -0,0 +1,61 @@ | |||
| package apicid | |||
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.
api sounds a bit weird here, I'd probably just move this into cidenc
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.
It may sound weird but that is the exact idea I want to capture. This package present a form of the Cid to use in the API struct. The only reason it is here is because this type might need to be used outside of go-ipfs.
cidenc/encoder.go
Outdated
| func extractCidString(p string) string { | ||
| segs := path.FromString(p).Segments() | ||
| v := segs[0] | ||
| if v == "ipfs" && len(segs) > 0 { |
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.
ipld is a valid prefix too. I also think that FromPath should be somehow integrated into CoreAPI or somewhere like that like that as having this package depend on go-path is going to hurt us eventually
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.
The idea here is extract the CID from a string which can either be just a Cid or a ipld path. I was not aware that ipld can be used but will fix that. I am not super happy with the go-path dependency either. I am open to other ways to do this.
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.
Doing this the way described in ipfs/kubo#5789 (review) should remove the need for this method
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.
Also note that the FromPath function doesn't strictly need to be here. It can be moved back into go-ipfs as only code in go-ipfs uses it for now.
| return str | ||
| } | ||
|
|
||
| // ScanForCid scans bytes for anything resembling a CId. If one is |
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.
s/CId/Cid/
Also remove other now unused code.
|
Note: This p.r is superseded by #10 but it has a lot of useful code in it that might still be useful to get in. I am closing but please don't delete the branch. |
No description provided.