View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006317 | unreal | ircd | public | 2023-07-17 05:55 | 2023-07-23 18:42 |
| Reporter | Assigned To | syzop | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Summary | 0006317: Switch to a Standardized Format for the configuration file in version 7.0 | ||||
| Description | UnrealIRCd currently uses it's own proprietary configuration file format, which often changes per major release. I think for UnrealIRCd 7.0 we should start looking at using a standardized format. This will allow syntax highlighting in any text editor, out of the box, which would make configuring much easier on our eyes. Also using a standardized format would allow parsing of the config file to happen, instead of having to code something that can specifically parse unreal's config. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I wouldn't claim it's proprietary, just take a look at BIND config files (the DNS server). The configuration format is the same for the past 20+ years, the only change being that we made a ; after a } optional, which is something I did in 2018, but you can still happily use }; everywhere if you want to, there is no plan for deprecation of that. I even recently learned we also support hybrid/ratbox/.. config file format as well! You know, the one which goes by name = value and such. Though I guess you call that proprietary as well :D. Anyway, I have not heard any complaints about our config file, to the contrary actually, I only heard sighs of relief that we don't use something like XML of InspIRCd. Many, really many, people hate that. I don't think we should change configuration formats just because it is not supported by your editor by default or less common, that would be quite evil towards all our existing users for no real benefit really. That doesn't mean that it isn't a valid question if we shouldn't support ANOTHER configuration format! Like an additional format, which is sometimes employed by other software (I know software that supports 3 different configuration formats). Like JSON in addition. I think that is not a weird suggestion. But after thinking carefully about this - which is why i have not reacted immediately to this bug - i have decided not to go that route. While I do like JSON (I am a fan!), I don't think we should either switch to JSON completely, nor should we support JSON "in addition to". The reason for the latter is not so much that parsing it is difficult (it is not), but mostly related the documentation (and perhaps error messages). I think if you support both configuration formats then your documentation should also show both configuration formats everywhere and that would really be a lot and major work, and.. wouldn't it make things more confusing? Same for guides, examples, discussions.I have to look at the "benefit" of all this, is all that worth it? No, I think the benefit is really small. We can always revisit this idea in say, 3 years from now, but for now I don't think the benefit vs investment is worth it. I've seen on IRC some people giving you advice on an editor for syntax highlighting that works, I think that is a bit out of scope to discuss here ;-) |
