Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Please consider exposing multicodec along with other dependencies #1913

Closed
Gozala opened this issue Mar 8, 2019 · 6 comments
Closed

Please consider exposing multicodec along with other dependencies #1913

Gozala opened this issue Mar 8, 2019 · 6 comments
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue P3 Low: Not priority right now

Comments

@Gozala
Copy link
Contributor

Gozala commented Mar 8, 2019

I'm working on https://github.com/gozala/ipdf/ where I need to encode codec format in the buffer before encrypting it so during encryption I can figure out what format to use in decoding.

Provided an ipfs node instance implementation has access to everything it needs to do it's job except of multicodec that IPFS implementation internally depends upon. Please consider exposing it along with other dependencies in ipfs.types. as that would avoid pulling in separately library & any versioning mismatches that could arise from that.

@alanshaw
Copy link
Member

alanshaw commented Mar 8, 2019

SGTM, what other dependencies would be useful?

@alanshaw alanshaw added exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue status/ready Ready to be worked P3 Low: Not priority right now labels Mar 8, 2019
@Gozala
Copy link
Contributor Author

Gozala commented Mar 11, 2019

SGTM, what other dependencies would be useful?

Not sure, have not come across anything else yet, I'll open separate issues if I will.

One thing that might be worth considering is to expose types / utils such that they can be accessed without instantiation of IPFS node maybe as static field on the constructor ? In lunet codebase I found myself having to pass IPFS instance to some functions just so I could use CID. I could use lazy initialization however that introduces timing and indirection that I would much rather not have to deal with.

@alanshaw
Copy link
Member

One thing that might be worth considering is to expose types / utils such that they can be accessed without instantiation of IPFS node maybe as static field on the constructor ?

This is how it will be in 0.35 when released :D see #1908

@niinpatel
Copy link
Contributor

niinpatel commented Mar 12, 2019

Can I take up this issue @alanshaw ?

@alanshaw
Copy link
Member

Yes please!

@niinpatel
Copy link
Contributor

PR is ready #1921

@ghost ghost removed the status/in-progress In progress label Mar 13, 2019
alanshaw pushed a commit that referenced this issue Mar 13, 2019
resolves #1913

License: MIT
Signed-off by: Nitin Patel <nitinpatel278@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue P3 Low: Not priority right now
Projects
None yet
Development

No branches or pull requests

3 participants