ipfs / ipfs/kubo

coreunix: simplify `Adder` structure

Open
#5,062 1 comment 0 reactions 0 assignees View on GitHub
topic/docs-ipfs topic/files
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.