[SSSD] Multi-line values in INI

Jeff Schroeder jeffschroed at gmail.com
Thu Apr 15 14:21:16 UTC 2010


On Thu, Apr 15, 2010 at 6:23 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>
> Can we please come at this issue from the right direction? The reason
> that this is even being debated is because we learned of another program
> (certmonger) that is using INI files to store binary data.
>
> THIS IS WRONG.
>
> This is not an appropriate use-case for the INI file format, and is not
> an example to follow. For storing binary data, there are plenty of more
> sensible formats, such as yaml. In the particular case of certmonger, an
> SQLite database or other small embedded DB would be a much better idea.
> This is not my project, so it's not my concern.
>
> We need to establish what the goals are for an INI file. In the vast
> majority of cases (including the SSSD), they are used as a configuration
> file for a program. Configuration files are expected to set
> site-specific values for the execution of a program. Storage of data
> should be relegated to a file format suitable for data storage.
>
> So, it follows that for libini_CONFIG, we should only expect to
> reasonably store configuration data. So here's my proposal for what we
> should do:
>
> 1) First and foremost: as far as libini_config should be concerned, ALL
> values should be treated as a single buffer. We should not offer to
> handle escapes at all. This means that if the literal characters "\n"
> appear in the string, they should be passed to the INI consumer as two
> characters: a backslash followed by the letter n.
>
> If the consumer of libini_config wishes to convert the string they got
> back, it is up to them. We should only be in the business of returning
> the exact contents of the value.
>
> 2) Leading whitespace should be ignored on all lines. This means that
> name = value
> should result in the returned string "value" with no exceptions. If for
> some reason the consumer of the interface needs leading whitespace, it
> should be up to them to determine a reasonable way to denote this in
> their source code.
> They might decide to quote the whole string:
> name = "   value"
> or they might decide to represent leading spaces with an escape of their
> design:
> name = %s%s%svalue
> We would return these literal strings as
> "   value"
> and
> %s%s%svalue
> respectively
>
>
> 3) Newlines should be handled as described in RFC822. In other words,
> there need be no backslash escape denoting the end of the line. If the
> libini_config parser detects a newline, it should check the first
> character of the next line. If this character is a space or tab, the
> parser should insert exactly one space in the resulting string.
>
> name = value
>  continued value
>            continued value2
> <tab>continued value3
>
> Would be returned to the caller as:
> value continued value continued value2 continued value3
>
> If the caller wanted to ensure that there were actual newlines and/or
> exact spaces, then they would be required to add their own escapes and
> post-process the return from libini_config.
>
>
> In conclusion: I think attempting to solve the newline/escape problem in
> libini_config itself is both too complex and too limiting. It is more
> complexity being added to the libini_config than a simple INI file
> parser needs to have, and by implementing any particular approach to
> managing the data, we are limiting is usability to only those use-cases
> that we can come up with.
>
> --
> Stephen Gallagher
> RHCE 804006346421761

You nailed my thoughts exactly Stephen. Very well said.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the sssd-devel mailing list