RFC: escape strings in KConfigBase

[Andreas Hartmetz]

On Tuesday 15 May 2007 10:19:59 Thiago Macieira wrote:
> Olivier Goffart said:
> > Le mardi 15 mai 2007, Andreas Hartmetz a écrit :
> >> Hello list,
> >>
> >> I noticed that KConfigBase has some "forbidden" chars in certain fields,
> >> quote:
> >> "the '=' char is not allowed in keys and the ']' char is not allowed in
> >> a
> >> group name."
> >> ...and another char, ',' by default, is also forbidden if you want to
> >> use
> >> the (very convenient) list read/write functions.
> >> This is not state of the art, dangerous (who knows which strings happen
> >> to
> >> turn up in your config file), and cumbersome.
> >
> > I also already had the problem (in my case this was with ',' in lists)
>
> Values should be obviously escaped. It makes no sense to restrict what
> values we can save in our config files.
>
> Keys, on the other hand (entry names and section names), I am not so sure.
> If we can allow everything, that would be great, but I wouldn't want the
> code to become too complex or incompatible with existing installations
> just to provide that.
>
> You don't save user strings in keys. If your program is doing that, I
> submit that you should redesign it.
>
Yeah I don't, actually. But what is to be won by imposing restrictions on 
keys' names?
Suppose that you let users define configurable little things and your users 
are also allowed to name them. The little things will be nicely separated 
from the rest of your settings by putting them in their own group. Now you 
have to make up names like "item0001" and put the name in the value. If you 
want to access your items by name and it should be fast, you now have to use 
another QHash in your program.

> >> I can come up with three possible solutions:
> >> - Auto-escape all strings, using the backslash notation if nothing
> >> better
> >> (i.e. faster to parse and still human readable) exists.
> >> - Provide an escape function that takes the chars to escape as a
> >> parameter
> >> - Add Escape/NoEscape as flags to the write/read functions.
> >
> > I vote for automatic escape using backslash notation.
> >
> > I don't see any case where you wouldn't want to escape.
>
> I am not sure backslash escaping is the best solution. But I'll leave that
> to whomever actually writes the code.
>
> One point, though, is that we should strive to retain compatibility with
> other installations. Any escaping done must take that into consideration.
>
> Remember that our config files share the same INI format as desktop files
> and those are quite strict. If we change our config format, we have to be
> careful not to propagate any side-effects to desktop files. (where
> side-effects = incompatible format changes)
>

http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.4.html#basic-format

Gah, this spec is stup^H^H^Huboptimal in some ways.

"Some keys can have multiple values; these should be separated by a semicolon. 
Those keys which have several values should have a semicolon as the trailing 
character. Semicolons in these values need to be escaped using \;"

and

"The escape sequences \s, \n, \t, \r, and \\ are supported, meaning ASCII 
space, newline, tab, carriage return, and backslash, respectively." [1]

They could have gone the extra millimeter and allow escapting of [,],=,# but 
nooo...

Another thing to notice is that desktop files and KDE actually use different 
list entry delimiters by default (';' vs. ','), and that the spec says that 
lists should have a trailing ';'. [2]

Can you tell which programming language the creators of [1] and [2] use a lot, 
and maybe a bit too much? :)

So - KDE actually doesn't implement the desktop file standard to the letter 
anyway [which should change], so what about a KDesktopFile that doesn't 
inherit KConfigBase?
Or what about this - a KConfigBase with a strict mode (as in "actually 
conforming to the desktop file spec") and a KDE mode with better escaping 
rules.
Desktop files are desktop files and config files are different. They don't 
have to be compatible except for ease of implementation.

> What's more, there's KDE 3 compatibility to keep in mind. For one thing,
> we'll be reading KDE 3 config files for a while, even if we update it on
> save. For another, some of the config files we write will be read by KDE 3
> applications (think kdeglobals).

kdeglobals is supposed to be shared between KDE versions? Oops.
That needs more thinking.