Run-time format selection

[zah]

Currently, Chronicles allows you to specify the output format associated with a particular sink at compile-time, but some apps may require the format to be specified at run-time on the command-line or within a config file.

Adding support for this boils down to the creation of a new DynamicLogRecord type with a generic tuple parameter FormatsList. At compile-time, the user will specify the list of formats that will be compiled in the program. At run-time, each chronicles stream using dynamic log records as its output type will also carry a numeric index of the currently active format. Each written property in a log statement uses the active index to perform a lookup in a table of functions associated with the logged property type and thus the right output type is selected at run-time (similar to a virtual function call in C++).

[disruptek]

Why not use strings instead of numeric indexes?

[zah]

The numeric indices will be more efficient. But perhaps you are not imagining this correctly. Each log statement is supposed to work very similarly to a C++ virtual function call (backed by a vtable). Would you propose these to be backed by string hash tables?

Of course, the configuration and some parts of the APIs will rely on strings to identify the different formats.

[disruptek]

Yes. I think a string is a much more useful type to pass around. What happens under the covers isn't important to me as a user.

[disruptek]

To put this another way, I don't see the value in having a seemingly random index in my dynamic log record output. The means by which I make sense of this index elsewhere will be fairly brittle, right?

[zah]

The index is purely an implementation mechanism. It won't appear in the log output. It appears only in the memory of the program as a field of a particular log stream. Its only purpose is to select the log formatting function that will transform the strongly-typed logged properties to the serialized output of the particular formats offered as a run-time choice (e.g. json, xml, textlines, etc).

The high-level API can work with symbol names (because each format in nim-serialization has an associated symbol).

myLogStream.setOutputFormat(Json)

This makes sure that the programmer cannot introduce a typo in the code (or forgot to change a format name during refactoring).

[disruptek]

Ah, gotcha; sounds good!

[Benjamin-Lee]

This would be a great addition. For my use case, I'm building a CLI tool that will need the ability to configure the format at run time since I'm planning on distributing it in a way that doesn't require the users (bioinformaticians) manually compile.