coreunix: simplify `Adder` structure
- Dominant language
- Go
- Stars
- 17.1k
- Forks
- 3.2k
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 11
Description
This structure seems to handle a lot of information and has many responsabilities which makes it harder to understand the `ipfs add` process.
https://github.com/ipfs/go-ipfs/blob/7853e53860805e08a212d78c4baa5d59bff99ba8/core/coreunix/add.go#L71-L93
I'm still not sure how to go about this (besides adding comments), I'm leaving some ideas for now.
* Encapsulate `ipfs add` options in a separate structure, these make up for nearly half of it and seem secondary to the core process.
* Encapsulate (or at least separate with comments and blank lines) the expanded IPFS node components, `Pinner`, `GCBlockstore`, `DAGService`. Could these be accessed now from the Core API?
* Clearly differentiate between (`ipld.Node`) `root` and (`mfs.Root`) `mroot` (a relationship that has to be first elucidated in https://github.com/ipfs/go-ipfs/issues/5059).
Contributor guide
Research direction
Start with core/coreunix/add.go at the Adder definition linked in the issue, then read issue 5059 to clarify the root and mroot relationship. Investigate how add options and the Pinner, GCBlockstore, and DAGService components are used before choosing boundaries; done would mean a simpler Adder with clearly separated responsibilities and terminology.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, cli
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100