# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 10
# self = https://watcher.sour.is/conv/3syipzq
lyse
lyse.isobeef.org
View Thread
Yeah, the lack of comments makes regular JSON not a good configuration format in my view. Also, putting all keys in quotes and the use of commas is annoying. The big upside is that's in lots of standard libraries.

I think the appeal with YAML is that is has comments, is kind of easy to write and read and also provides unlimited nesting levels. But it has all its drawbacks, no question. Forbidding tabs, thousands of different string flavors, having so many boolean options (poor Norwegians) etc. I use it, but I don't particularly enjoy it.

Among simple key value pairs, I like INI files, but with # for comments, not ;. I never used TOML, read up on it yesteray before writing this question, but it looks a bit weird and has some strange rules. I guess I have to give it a try one day.

And yes, as mentioned by several of you, it always depends on the complexity of the configuration at hand.

I'm developing something for the scouts at the moment with rather simple requirements on the config. Currently, there are just four settings. Even INI would be overkill with its section. I selected JSON for now, because that's readily available with Go's std lib. But I do not like it.

Btw. what's your own config format, @xuu?
xuu
txt.sour.is
View Thread
@lyse its a hierarchy key value format. I designed it for the network peering tools i use.. I can grant access to different parts of the tree to other users.. kinda like directory permissions. a basic example of the format is: 


@namespace
# multi
# line
# comment
root :value

# example space comment
@namespace.name space-tag 

# attribute comments
attribute attr-tag  :value for attribute

# attribute with multiple 
# lines of values
foo :bar
      :bin
      :baz

repeated :value1
repeated :value2



each @ starts the definition of a namespace kinda like [name] in ini format. It can have comments that show up before. then each attribute is key :value and can have their own # comment lines.
Values can be multi line.. and also repeated..

the namespaces and values can also have little meta data tags added to them.



the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.
xuu@dev.txt.sour.is
dev.txt.sour.is
View Thread
@lyse its a hierarchy key value format. I designed it for the network peering tools i use.. I can grant access to different parts of the tree to other users.. kinda like directory permissions. a basic example of the format is: 


@namespace
# multi
# line
# comment
root :value

# example space comment
@namespace.name space-tag 

# attribute comments
attribute attr-tag  :value for attribute

# attribute with multiple 
# lines of values
foo :bar
      :bin
      :baz

repeated :value1
repeated :value2



each @ starts the definition of a namespace kinda like [name] in ini format. It can have comments that show up before. then each attribute is key :value and can have their own # comment lines.
Values can be multi line.. and also repeated..

the namespaces and values can also have little meta data tags added to them.



the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.
xuu@dev.txt.sour.is
dev.txt.sour.is
View Thread
I can query the configurations a few different ways. i can request the specific name foo.bar or a glob like foo.* or trace the hierarchy trace:some.deep.name.space which will give me the namespaces some, some.deep, some.deep.name, and some.deep.name.space. These can be combined.
xuu
txt.sour.is
View Thread
I can query the configurations a few different ways. i can request the specific name foo.bar or a glob like foo.* or trace the hierarchy trace:some.deep.name.space which will give me the namespaces some, some.deep, some.deep.name, and some.deep.name.space. These can be combined.
xuu
txt.sour.is
View Thread
and then i have a compact version that makes things more grep'able in scripts.

xuu@dev.txt.sour.is
dev.txt.sour.is
View Thread
and then i have a compact version that makes things more grep'able in scripts.

lyse
lyse.isobeef.org
View Thread
@xuu Cool! I particularly like the idea of converting it into a grep-able version, that's very neat. Interesting choice of aligning the colons at the values and not the keys, I think I never came across this.
eapl.me
eapl.me
View Thread
well, at work we use JSONC which basically is JSON + // and /* */
eapl.me
eapl.me
View Thread
well, at work we use JSONC which basically is JSON + // and /* */
Its syntax is supported by vs code, and we wrote a few scripts to remove the comments so it's practically compatible with anything
It's day and night not only for configuration but for testing and development.