3 ms·

Instead of making a brutal narrow spec that snubs ease of use & extensibility, just to create a "last breaking change" forever spec, the spec should definitely

Instead of making a brutal narrow spec that snubs ease of use & extensibility, just to create a "last breaking change" forever spec, the spec should definitely just keep dropping new major versions when it needs to change. This is an ugly & rough conceitedness propsed here: no one can do anythint, because we reserve the right to do anything, and we dont want to have to drop a new major version to do it. Craven attitude. Building ultra-strict narrow protocols like this should be highly highly discouraged. This is such a mean & awful tradeoff to foist upon people; I cant see any advantage to making a brittle, narrow, but forever "safe" little path like this. Be braver.

vincnetas 4y ago
Are you saying that exact and precise specifications are bad? Can you elaborate, because i always thought that the opposite is bad.
- deleted 4y ago
  [deleted]
EdwardDiego 4y ago
> brutal > ugly & rough conceitedness > Craven attitude > mean & awful Why do you phrase it in such emotive terms?
- rektide 4y ago
  It's a terrible & self-interested & small-minded design philosophy making awful trade-offs. It's an actively dangerous way of building, to the exclusion of allowing possibility, and for false gain ("no new major versions but it will totally change maybe & no one else has freedom"). I use strong terms because this breaks so many internet ethos, logos, & pathos. Picking the narrowest path should be warded & hazarded against in strong terms. This reaction is emotional because it's terrible terrible choices. Postel's Law[1] has come under fire from some pretty conservative-minded viewsets (and frankly I'be rarely been persuaded by the angst against permit-if-you-can), but this is a next level assault on loose-coupling, a stark new frontier in reserving almost all possibility for yourself. My description while strong is accurate in many ways: this is brutally narrow. This is an extremeist perspective that json schema is embarking towards, snubbing basic protocol design & rejecting a non-harmful extensibility that cost them nothing (besides needing to tick a major version to make a major change). [1] https://en.m.wikipedia.org/wiki/Robustness_principle https://en.m.wikipedia.org/wiki/Robustness_principle
  - mst 4y ago
    They've explicitly said they're looking at finding a way to still be able to express custom properties. So done right the end result will be basically no different from the use of X- headers in HTTP and friends. What they're talking about doing could easily be -implemented- badly, but your reaction to the idea of doing it at all seems rather more exothermic than indicated by the situation.
    - rektide 4y ago
      RFC 6648 deprecated the X- header prefix. It turned out to be ridiculously hand-wringing a concern & just makes a noisey prefix that still results in name clashes anyways. I wish they'd actually elaborated like a dozen cases in the wild, that show there's a real problem here & why they'd do this. I agree, Im having a strong reaction to this. It really seems like any workarounds that happens here are going to be ugly, going to be gross, and it feels like such a false need, such a non-issue to make new problems over. https://www.rfc-editor.org/rfc/rfc6648 https://www.rfc-editor.org/rfc/rfc6648

vincnetas 4y ago

Are you saying that exact and precise specifications are bad? Can you elaborate, because i always thought that the opposite is bad.

deleted 4y ago
[deleted]

EdwardDiego 4y ago

> brutal > ugly & rough conceitedness > Craven attitude > mean & awful Why do you phrase it in such emotive terms?

rektide 4y ago
It's a terrible & self-interested & small-minded design philosophy making awful trade-offs. It's an actively dangerous way of building, to the exclusion of allowing possibility, and for false gain ("no new major versions but it will totally change maybe & no one else has freedom"). I use strong terms because this breaks so many internet ethos, logos, & pathos. Picking the narrowest path should be warded & hazarded against in strong terms. This reaction is emotional because it's terrible terrible choices. Postel's Law[1] has come under fire from some pretty conservative-minded viewsets (and frankly I'be rarely been persuaded by the angst against permit-if-you-can), but this is a next level assault on loose-coupling, a stark new frontier in reserving almost all possibility for yourself. My description while strong is accurate in many ways: this is brutally narrow. This is an extremeist perspective that json schema is embarking towards, snubbing basic protocol design & rejecting a non-harmful extensibility that cost them nothing (besides needing to tick a major version to make a major change). [1] https://en.m.wikipedia.org/wiki/Robustness_principle https://en.m.wikipedia.org/wiki/Robustness_principle
- mst 4y ago
  They've explicitly said they're looking at finding a way to still be able to express custom properties. So done right the end result will be basically no different from the use of X- headers in HTTP and friends. What they're talking about doing could easily be -implemented- badly, but your reaction to the idea of doing it at all seems rather more exothermic than indicated by the situation.
  - rektide 4y ago
    RFC 6648 deprecated the X- header prefix. It turned out to be ridiculously hand-wringing a concern & just makes a noisey prefix that still results in name clashes anyways. I wish they'd actually elaborated like a dozen cases in the wild, that show there's a real problem here & why they'd do this. I agree, Im having a strong reaction to this. It really seems like any workarounds that happens here are going to be ugly, going to be gross, and it feels like such a false need, such a non-issue to make new problems over. https://www.rfc-editor.org/rfc/rfc6648 https://www.rfc-editor.org/rfc/rfc6648