-
Notifications
You must be signed in to change notification settings - Fork 10
change the Pinner interface to have async pin listing #24
Conversation
8a58bcf
to
9da23c3
Compare
Original change: ipfs/go-ipfs-pinner#24
02fd0c3
to
7b89c83
Compare
Original change: ipfs/go-ipfs-pinner#24
Original change: ipfs/go-ipfs-pinner#24
7b89c83
to
e9bb752
Compare
Original change: ipfs/go-ipfs-pinner#24
Original change: ipfs/go-ipfs-pinner#24
Corresponding Kubo PR: ipfs/kubo#9692 |
@@ -3,6 +3,7 @@ module github.com/ipfs/go-ipfs-pinner | |||
go 1.19 | |||
|
|||
require ( | |||
github.com/Jorropo/channel v0.0.0-20230303124104-2821e25e07ff |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we not add this dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to return a union of "val or err" from a chan, then it's perfectly idiomatic to return a struct { Pin coreiface.Pin, Err error}
, I'd prefer not to add another module to our rat's nest of dependencies for something that already has an established idiom.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
has an established idiom
I don't belive that true, most code in the std is synchronous or uses methods of interface who secretly manage synchronisation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need a dependency for this. Please don't do it
@@ -119,14 +120,14 @@ type Pinner interface { | |||
Flush(ctx context.Context) error | |||
|
|||
// DirectKeys returns all directly pinned cids | |||
DirectKeys(ctx context.Context) ([]cid.Cid, error) | |||
DirectKeys(ctx context.Context) channel.ReadOnly[cid.Cid] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DirectKeys(ctx context.Context) channel.ReadOnly[cid.Cid] | |
type StreamedCid struct { | |
C cid.Cid | |
Err error | |
} | |
DirectKeys(ctx context.Context) chan StreamedCid |
The rational is that if the pin list get big, a synchronous call to get the complete list can delay handling unnecessarily. For example, when listing indirect pins, you can start walking the DAGs immediately with the first recursive pin instead of waiting for the full list. This matters even more on low power device, of if the pin list is stored remotely. Replace: - ipfs/go-ipfs-pinner#24 - ipfs/go-ipfs-provider#48
The rational is that if the pin list get big, a synchronous call to get the complete list can delay handling unnecessarily. For example, when listing indirect pins, you can start walking the DAGs immediately with the first recursive pin instead of waiting for the full list. This matters even more on low power device, of if the pin list is stored remotely. Replace: - ipfs/go-ipfs-pinner#24 - ipfs/go-ipfs-provider#48
The rational is that if the pin list get big, a synchronous call to get the complete list can delay handling unnecessarily. For example, when listing indirect pins, you can start walking the DAGs immediately with the first recursive pin instead of waiting for the full list. This matters even more on low power device, of if the pin list is stored remotely. Replace: - ipfs/go-ipfs-pinner#24 - ipfs/go-ipfs-provider#48
The rational is that if the pin list get big, a synchronous call to get the complete list can delay handling unnecessarily. For example, when listing indirect pins, you can start walking the DAGs immediately with the first recursive pin instead of waiting for the full list.
This matters even more on low power device, of if the pin list is stored remotely.
Corresponding Kubo PR: ipfs/kubo#9692