Request for feedback: Nimrod configuration

[Sergio Bossa]

Hi all,

current Nimrod configuration describes the logs to listen to and process, with related source and interval, and the metrics store type, either memory or disk.

This is currently expressed with Java properties as follows, and everything works well:

nimrod.logs = 1:log1.txt:1000,2:log2.txt:1000

nimrod.store = memory

By the way, adding more logs-related properties is going to be cumbersome, so I was evaluating alternative configuration formats, in particular:

1) JSON

2) YAML

3) HOCON from Typesafe guys (https://github.com/typesafehub/config/blob/master/HOCON.md)

I already tried JSON, and it looks quite verbose.

Still didn't try YAML, but made a quick HOCON-based implementation, and it looks imho quite readable:

logs {

    1 { 

        source : log1.txt

        interval : 1000

    }

    2 { 

        source : log2.txt

        interval : 1000

    }

}

store {

    type : memory

}

Surely, converting the snippet above to YAML would remove brackets, but I don't feel fully confortable with indentation-based approaches.

Another alternative could be Clojure maps.

So what's your take? Any feedback will be greatly appreciated.

Cheers!

Sergio B.

--
Sergio Bossa
http://www.linkedin.com/in/sergiob

[Tatu Saloranta]

On Thu, Jan 19, 2012 at 12:34 AM, Sergio Bossa <sergio...@gmail.com> wrote:
> Hi all,
>
> current Nimrod configuration describes the logs to listen to and process,
> with related source and interval, and the metrics store type, either memory
> or disk.
> This is currently expressed with Java properties as follows, and everything
> works well:
>
> nimrod.logs = 1:log1.txt:1000,2:log2.txt:1000
> nimrod.store = memory
>
> By the way, adding more logs-related properties is going to be cumbersome,
> so I was evaluating alternative configuration formats, in particular:
>
> 1) JSON
> 2) YAML
> 3) HOCON from Typesafe guys
> (https://github.com/typesafehub/config/blob/master/HOCON.md)

I must say that for me plain old Java properties often work pretty
well. As much as I like JSON for data transfer, I don't think it is
particularly good for configuration. Configuration may be one of few
use cases for which YAML works well.

-+ Tatu +-

[Sergio Bossa]

On Thu, Jan 19, 2012 at 5:58 PM, Tatu Saloranta <tsalo...@gmail.com> wrote:

I must say that for me plain old Java properties often work pretty
well. As much as I like JSON for data transfer, I don't think it is
particularly good for configuration. Configuration may be one of few
use cases for which YAML works well.

I think properties don't "scale" when having lots of children options. 

I agree YAML to be better than JSON for configuration, and what do you think about the "HOCON" snippet provided above?

[Árni Hermann Reynisson]

I vote for the HOCON format, it's looks nice.

On Jan 20, 3:52 pm, Sergio Bossa <sergio.bo...@gmail.com> wrote:

[Sergio Bossa]

2012/3/7 Árni Hermann Reynisson <arn...@gmail.com>

I vote for the HOCON format, it's looks nice.

 

Thanks for your feedback, upcoming 0.5 version will actually go with HOCON :) https://github.com/sbtourist/nimrod/issues/22

Cheers!

[Tatu Saloranta]

Hmmh. Somehow missed this -- sorry for slow reply.

Not 100% sure what to think of HOCON: I both like it, and dislike some
parts. Latter is mostly because if it wants to go above and beyond
JSON, it should do so... but it seems to be sort of minor addition,
then lots of convention. And most of those conventions can already be
used with JSON.

My point is this:

Since it is a superset of JSON, it will require custom parsers (and
generators if need be). Given this, why try to keep any other aspect
with JSON? You can't use any of existing tools, so why take any of the
limitations.
I'd rather think one would make good use of incompatibility, to add
things that JSON is missing.

That said, using this notation would probably work ok; just requires
yet another set of tools to operate on, but still might not be as
convenient to hand edit as YAML.

-+ Tatu +-