Refine foundations statements about pathing #157
Conversation
This is one of the trickier subjects to solidify our position on. We want the utility of some flexibility here; we also need to get that utility without totally letting the complexity demon out of the bag of holding. Hopefully these wordings communicate some of that.
I dunno, maybe that word is fine, but it seems like a one dollar word where a fifty cent word will do.
|
I think this is something I'd like to merge sooner than later, because it's clear that something needs saying on this topic -- but I'd also like a lot more in the way of scope clarifiers and limiters here. We've had some discussions in other channels about how part of our vision of "stablity"/"simplicity" might involve "spec first (code must be derived from it, not from copying other code)". Maybe we should make statements about that here? Maybe we should make another top-level heading about that, and refer to it here? Not sure how best to proceed; just know if feels like there should be more here. |
|
Maybe this needs to be another doc, but we should probably move pathed linking and relative linking into ‘high level pathing’ because there are some big difficulties in doing those well and reasoning about them without other high level pathing features. |
|
Yeah I just outright crossed those out in #153 (I... went a little PR-crazy after Rod (rightly) suggested there's a lot to digest in here, so, while hopefully the upside is "easier to review", the tradeoff might be "hard to find the right PR"...) I'd plus-one links-with-potentially-mid-block-paths and relative linking into a whole 'nother doc. Higher level pathing as discussed in the examples in this diff are still all single stride examples -- and those are a lot easier to deal with. The implications of the other two go way into deeper water. |
There was a problem hiding this comment.
I'm fine with this, but if it gets pulled into a separate doc then there still needs to be something to deal with the apparent conflict present in existing "pathing" details in this doc that, on their face, would preclude any kind of pathing occurring at a "higher level". As noted @ #152 (comment)
|
To clarify: I think the things in this diff here do belong in this doc; I think discussions of links that have paths (and thus implicitly may land on nodes that are mid-block), which are marked for removal in #153, continue to not belong in this doc (primarily because they aren't sufficiently explored). So I think we agree, in other words. |
Given that a whole bunch of breath is spent stating how these higher-level systems still aim to honor the basic principle, calling it "relaxed" seems... ahheh. This is not relaxing to specify ;)
|
This is double-approved, so merging. It might not be the final resting point of this text, but it seems improved, and describes our advancements. Thanks everyone for reviewing on what's a very subtle set of statements. |
Refine foundations statements about pathing
Add a section talking about higher-level pathing. The existing section about stable pathing is unchanged -- it's a good baseline.
This is probably one of the trickier subjects to solidify our position on. We want the utility of some flexibility here; we also need to get that utility without totally letting the complexity demon out of the Bag of Holding. Hopefully these wordings communicate some of that, but more explicit limitations and counter-examples would probably help further -- more wanted on that.
This extracts some content from #148, addressing the earlier review in #146 (comment), and from there I've added a bit more "motivations" text, taking @vmx's suggestions in https://github.com/ipld/specs/pull/148/files#r309143142.