-
Notifications
You must be signed in to change notification settings - Fork 6
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
WIP: Changes needed for --cid-base
option in go-ipfs.
#8
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
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.
@@ -150,3 +150,48 @@ func encode(base mb.Encoder, data []byte, strip bool) string { | |||
} | |||
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.