6 ms·

As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). T

As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). There still has to be a standard text format, but only for the source from which the live configs have to be built. Done right, this has several advantages: 1. Built-time validation (or at least type checking). 2. Built configs can be easy to parse but (potentially) rich enough to avoid confusing templating. 3. Separation of concerns between storing/maintaining configs and applying them. E.g. scoop text configs off a source repo, but send out binary configs over the network. All this is a fantasy in my head. Right now the closest mainstream thing is protobufs. But they make trade-offs for non-config use cases, and thus don't really cut it in the "... rich enough to avoid confusing templating" department.

becauseiam 7y ago
Property Lists already do tick some of those boxes.
zrail 7y ago
SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.
- zbentley 7y ago
  They don't type check though; most constraints arent enforced, and the underlying reality (slinging around mostly strings) leaks out often.
- raymondh 7y ago
  I agree this a pretty choice.
- shandor 7y ago
  But that, and the parent's idea of binary formats in general, throws away the absolute golden property of text format configuration files: you can put those in git, and see with an accuracy of a single character what has changed. My impression was always that this was a huge reason for plain text files in the first place. Someone mentioned protobufs, maybe with something like those one could have both?
  - geocar 7y ago
    > you can put those in git, and see with an accuracy of a single character what has changed. You can use sqldiff[1]. Try adding it to your .gitattributes[2]. If you need TRIGGERs and VIEWs, consider dumping your database[3] instead. [1]: https://www.sqlite.org/sqldiff.html https://www.sqlite.org/sqldiff.html [2]: https://git-scm.com/docs/gitattributes https://git-scm.com/docs/gitattributes [3]: https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff67f405af2909 https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff...
deleted 7y ago
[deleted]

becauseiam 7y ago

Property Lists already do tick some of those boxes.

zrail 7y ago

SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.

zbentley 7y ago
They don't type check though; most constraints arent enforced, and the underlying reality (slinging around mostly strings) leaks out often.
raymondh 7y ago
I agree this a pretty choice.
shandor 7y ago
But that, and the parent's idea of binary formats in general, throws away the absolute golden property of text format configuration files: you can put those in git, and see with an accuracy of a single character what has changed. My impression was always that this was a huge reason for plain text files in the first place. Someone mentioned protobufs, maybe with something like those one could have both?
- geocar 7y ago
  > you can put those in git, and see with an accuracy of a single character what has changed. You can use sqldiff[1]. Try adding it to your .gitattributes[2]. If you need TRIGGERs and VIEWs, consider dumping your database[3] instead. [1]: https://www.sqlite.org/sqldiff.html https://www.sqlite.org/sqldiff.html [2]: https://git-scm.com/docs/gitattributes https://git-scm.com/docs/gitattributes [3]: https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff67f405af2909 https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff...

deleted 7y ago

[deleted]