-
Notifications
You must be signed in to change notification settings - Fork 44
Conversation
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.
@lidel @aschmahmann This PR is what ipfs/kubo#7661 is using. The main difference here is that pinning services is a map[string]RemotePinService, as opposed to []RemotePinService. Any reason to prefer a slice? |
I don't have a strong preference for slice vs map, I think what @lidel was asking for was to do |
@petar I don't feel strongly either way, but we already use map[string] approach in Asks:
(updated my comment above to use it too) |
@lidel @aschmahmann What is the consensus design for the Policy field? map[string]string? I am looking into it as I'll need it for the MFS pinning feature. |
Initially we would have either none or only "all-in-mfs", but in the long run we want to be able to have more than one policy enabled (eg. "all-in-mfs" and "all-local-pins"), so either []string or map[string]bool(?) would work for ipfs-webui (as long we can read them back via Policy: ["all-in-mfs", "all-local-pins"] or Policy: {
mirrorMFS: true
mirrorLocalPins: true
} I don't know go(-ipfs) well enough to feel strongly either way – @aschmahmann thoughts? |
I don't have particularly strong feelings here, but probably maps/structs (where they're both the same in JSON, but structs allows us to be stricter in our Go code). We can also use I tried to look at what our other config options do, such as how the gateways have
This of course is no help since we've used both options inside of a single command. Nonetheless, I think the "UseSubdomains" boolean is a little closer to what we're looking for here since structs like this are "typed" and so a little stricter and simpler to work with. It could also make it easier to override defaults. Since maps ~ structs this means that if go-ipfs supports two policies "MirrorMFS" and "MirrorLocalPins" then we can say "by default local pins are duplicated remotely" (not necessarily a good idea, but for the sake of argument) and so MirrorLocalPins will default to true, while MirrorMFS defaults to false. If the user only sets MirrorMFS as true then MirrorLocalPins will remain the default instead of if it was an array where the user might not be sure if they were overriding MirrorLocalPins as false. Note I'm open to being told "having any remote pin default other than |
For what its worth, I can't come up with any policy that we would want to enable by default. IMO user agency takes a priority here. There should be no policies enabled: user needs to consciously opt-in. |
@lidel @aschmahmann I took a first stab at the MFS policy flag. See what you think. |
ab9c56f
to
280c4db
Compare
d405686
to
f5c0084
Compare
All MFS work has been moved to #116 |
f5c0084
to
26a8d86
Compare
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.
LGTM, but we may want to simplify names (either now or when MFS PR lands)
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.
LGTM
26a8d86
to
ad6e7f2
Compare
ad6e7f2
to
84cb43b
Compare
This is needed for ipfs/kubo#7661