Skip to content
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] Extract DAGService and friends #4063

Closed
wants to merge 2 commits into from
Closed

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented Jul 12, 2017

DO NOT MERGE!

Refactor IPFS to use: ipfs/go-ipld-format#8

Context: IPLD isn't currently very usable from libp2p because interfaces like the DAGService are bundled into go-ipfs. This PR extracts these interfaces and some of the related helper functions.

License: MIT
Signed-off-by: Steven Allen <[email protected]>
**DO NOT MERGE!**

Refactor IPFS to use: ipfs/go-ipld-format#8

Context: IPLD isn't currently very usable from libp2p because interfaces like
the DAGService are bundled into go-ipfs. This PR extracts these interfaces and
some of the related helper functions.

License: MIT
Signed-off-by: Steven Allen <[email protected]>
Copy link
Member Author

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, there are a few of things I'm not happy about.


EnumerateChildren takes a GetLinks function. Given that we've removed the GetLinks function from DAGService (made it a helper function that takes a NodeGetter), I'd like to just make EnumerateChildren take a NodeGetter.

edit: I've changed my mind now that I've read the relevant commit. However, I'm still confused about case 1 below.

There are two cases where this gets tricky:

  1. We use a GetLinksDirect function here (and a few other places). Why do we do this? Was there any reason to bypass the LinkService or are we doing this because we didn't have a LinkService? @kevina? (answered)
  2. We define a custom GetLinks function here that logs errors to a channel instead of returning them. I'd like to reimplement this as a custom NodeGetter.

Implementing OfflineNodeGetter can be a bit annoying.


GetMany should probably be moved to NodeGetter (from DAGService). This would allow more services to take NodeGetters instead of full DAGServices. Unfortunately, this would be yet another method that needs to be implemented on NodeGetters (I really wish golang had a concept of default implementations).

@@ -258,6 +258,10 @@ type Session struct {
ses exchange.Fetcher
}

func (s *Session) Blockstore() blockstore.Blockstore {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need this to implement OfflineNodeGetter() on sesGetter.

@@ -56,7 +56,7 @@ func (dbp *DagBuilderParams) New(spl chunk.Splitter) *DagBuilderHelper {
rawLeaves: dbp.RawLeaves,
prefix: dbp.Prefix,
maxlinks: dbp.Maxlinks,
batch: dbp.Dagserv.Batch(),
batch: node.Batching(dbp.Dagserv),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this name clear? Maybe BufferedDAGAdder (yuck!)?

t.size += len(nd.RawData())
if t.size > t.MaxSize || len(t.blocks) > t.MaxBlocks {
return nd.Cid(), t.Commit()
func GetLinksWithDAG(ng node.NodeGetter) GetLinks {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -548,7 +549,7 @@ func pinLsAll(typeStr string, ctx context.Context, n *core.IpfsNode) (map[string
if typeStr == "indirect" || typeStr == "all" {
set := cid.NewSet()
for _, k := range n.Pinning.RecursiveKeys() {
err := dag.EnumerateChildren(n.Context(), n.DAG.GetLinks, k, set.Visit)
err := dag.EnumerateChildren(n.Context(), dag.GetLinksWithDAG(n.DAG), k, set.Visit)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure EnumerateChildren has the right interface. IMO, it should be taking a NodeGetter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Stebalien I take it we cleared this up and you are okay with the current interface?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and thanks for answering my questions.

@kevina
Copy link
Contributor

kevina commented Aug 9, 2017

@Stebalien

We use a GetLinksDirect function here (and a few other places). Why do we do this? Was there any reason to bypass the LinkService or are we doing this because we didn't have a LinkService? @kevina?

Yes, because in some cases we need to make sure the nodes are available locally, using LinkService defeats this purpose. For example FetchGraph uses it when calling EnumerateChildrenAsync. If the link service was used then FetchGraph may not fetch some of the children (i.e. leaves).

@kevina
Copy link
Contributor

kevina commented Aug 9, 2017

And I should add that other times we don't care if the Nodes exist locally we just want to visit (i.e. call the visit function) for each Cid in the Dag. This is why EnumerateChildren/EnumerateChildrenAsync takes in a function that gets the links for a node, not the node itself.

Now that I think about it a bit, GetLinksDirect may not be strictly necessary as the visit function could retrieve the node itself (to make sure its available), but that just adds extra work.

In any case I am not sure how the presence of the GetLinksDirect effects your refactoring as it is a helper function not directly connected to the DAGService.

@Stebalien
Copy link
Member Author

In any case I am not sure how the presence of the GetLinksDirect effects your refactoring as it is a helper function not directly connected to the DAGService.

DAGService no longer has a GetLinks function (it's a helper function that takes a dag and a cid) so one has to construct a curried GetLinks.

@kevina
Copy link
Contributor

kevina commented Aug 11, 2017

DAGService no longer has a GetLinks function (it's a helper function that takes a dag and a cid) so one has to construct a curried GetLinks.

Oh, okay. Well I guess that is unavoidable as I hope we have established that EumerateChildren/EnumerateChildrenAsync should take a function that gets the links for a node, not the node itself.

@whyrusleeping
Copy link
Member

@Stebalien This looks good to me, i'm fine to get this moving forward

@Stebalien
Copy link
Member Author

(to explicitly keep this in the comment thread instead of quietly tracking my questions in my first comment)

@kevina got it, all questions answered. I'm moving forward with my original go-ipld-format PR as those changes appear to work.

@kevina
Copy link
Contributor

kevina commented Aug 18, 2017

@Stebalien I have not gone over this is with a fine-tooth comb, but I am also okay with moving forward on this.

@Stebalien
Copy link
Member Author

This has served its purpose. I'll revive when I make progress on the linked PR.

@Stebalien Stebalien closed this Sep 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants