Hi everyone,
thanks a lot for the input on the proposal, its really great such valuable feedback! And I think its a good sign that at least until now the format of the configuration file seems to be the most controversial part of the proposal ;)
I must admit I didn't really think about having access to the comments in the manager, but its a good point and I can see the value in that. I guess that comments being part of the data itself would be a solution that works for all the formats we listed, isn't it? We could simply introduce a "-comment" suffix that would work for every key. What I'm not sure about right now is how the respective Python libraries handle the ordering of keys. As Bernhard mentioned, the comment should be nearby the value it refers to. I guess the most common ordering would be alphabetical, so if we add a "-comment" suffix the comment would be listed below the value. We just have to make sure comment and value are kept together when the file is updated programmatically.
One other thing that might be relevant: I think the manager should not have to deal with the file-format IntelMQ uses internally. I think the communication between API and intelmq-manager should still use JSON, and the conversion should be done by the API, but I don't think that would be a problem.
cheers, Birger
On 12/18/20 6:45 PM, Bernhard Reiter wrote:
Hi Filip,
thanks for the discussion, I'll answer you and Aaron in one go:
Am Dienstag 15 Dezember 2020 19:43:25 schrieb Filip Pokorny:
It doesn't improve GUI approach via Manager, but it doesn't break it or remove functionality either.
I think it would in a subtle way. (My aim is to point that way out first, not to recommend a decision in one or the other way.)
Usually an out-of-band comment has interesting info (otherwise it would be senseless) and the info is related to the values nearby.
So if the gui (editor) changes the value and cannot see the out-of-band comment, but preserves it, the comment will not match the value anymore and that the comment will be potentially broken. So one system will be the leading system unless all comments are in-band.
Am Dienstag 15 Dezember 2020 17:25:21 schrieb L. Aaron Kaplan:
But in the past, the very long JSON (no comments) format has been, well.. a bit cumbersome.
Optional in-band comments could be introduced. The default formatting could be made human readable and compact.
Otherwise the length maybe a problem of putting to much into one file?
How do other projects do their config language for large and complex configs?
I guess there is no silver bullet, each product will look at its requirements and use cases. Some put "config" data not into a "language", but consider it internal state that is managed by frontends.
Best Regards, Bernhard
IntelMQ-dev mailing list IntelMQ-dev@lists.cert.at https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev