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

API Todos #5

Open
whyrusleeping opened this issue Mar 20, 2017 · 6 comments
Open

API Todos #5

whyrusleeping opened this issue Mar 20, 2017 · 6 comments

Comments

@whyrusleeping
Copy link
Member

  • Move dagservice interface definition here
  • Remove ResolveLink method from interface. Add helper function to this package instead
  • Standardize errors from implementation packages into here (ErrNoSuchLink, ErrNotLink, etc)
@whyrusleeping
Copy link
Member Author

Also make Link an interface

@ghost
Copy link

ghost commented Mar 21, 2017

Let's do this now while we're making Link part of the coreapi?

@Stebalien
Copy link
Member

  1. Don't use Links, those have name/size fields and are IPFS specific.
  2. Remove the Copy() method. Generic nodes are supposed to be immutable so it only really makes sense to copy them once they've been downcast to a concrete node type.
  3. Move Stat() to an IPFSNode type (not in this package).
  4. Either move Size() to Block or remove it. It currently means two different things in different places (`ProtoNode.Size() computes the size of the dag, current node + linked nodes).
  5. Whatever we do with Size(), it shouldn't be able to return an error (given that one can compute it with uint64(len(node.RawData())).

@Stebalien
Copy link
Member

@Stebalien
Copy link
Member

Move dagservice interface definition here

#8

Standardize errors from implementation packages into here (ErrNoSuchLink, ErrNotLink, etc)

#13

Remove ResolveLink method from interface. Add helper function to this package instead

Having a ResolveLink method on the interface could be useful optimizing link traversal. However, a better way to do this would be specialization (or whatever go calls it): Define the helper function, define a NodeWithResolveLink interface, and then try to cast to NodeWithResolveLink in the helper function. This way, implementers can optimize multi-hop link resolution by implementing this interface but they don't need to.

Also make Link an interface

Or just use CIDs (#9)?


For context, I'm trying break this issue into actionable smaller issues and close it.

@ghost
Copy link

ghost commented Aug 6, 2017

Need some orientation. What are the use cases for ResolveLink?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants