RFC: escape strings in KConfigBase

[Andreas Hartmetz]

On Tuesday 15 May 2007 19:49:26 Oswald Buddenhagen wrote:
> On Tue, May 15, 2007 at 06:49:51PM +0200, Andreas Hartmetz wrote:
> > On Tuesday 15 May 2007 16:28:28 Oswald Buddenhagen wrote:
> > > On Tue, May 15, 2007 at 11:30:59AM +0200, Andreas Hartmetz wrote:
> > > > On Tuesday 15 May 2007 10:19:59 Thiago Macieira wrote:
> > > > > 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?
> > >
> > > back then simplicity, now compatibility ...
> >
> > Compatibility with - old KDE versions, the desktop file specification,
> > (...)?
>
> both, one would think.
>
I just think that a little backwards compatibility here and there will 
together make your software much worse in the long run. If you wouldn't have 
done it the same way now, time to change.

KDesktop file should, of course, conform to the spec. No problem - just don't 
make it inherit KConfigBase, or add any special cases to KDesktopFile. A 
desktop file is actually quite a bit different from a generic config file 
anyway.

By the way, Qt's QSettings does not impose any restrictions on key or value 
strings, even for the INI format. The only limitation (that they can't do 
anything about) is case insensitivity for INI files' keys.
Is that also bad?

> > KConfigBase at the moment is NOT compatible with the desktop file
> > standard and so KDesktopFile isn't, either.
> > Incompatibilities are the list delimiter char (the default one) and
>
> see bottom.
>
> > (surprise) legal desktop file escape sequences not supported by
> > KConfigBase, specifically \s, \n, \t, \r.
>
> indeed. because this is a storage backend detail and consequently
> handled by kconfigini.
>
>(...)
> yes. if you really want speed, you don't use strings. if you need to deal
> with strings (because they are the primary object), some config lookups
> are usually no problem. if you need to do lots of config lookups you are
> better off crafting your own hash - kconfig has a lot of overhead in any
> case.
>
This is a minor point, really. Let's just forget it.

> > > > "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...
> > >
> > > escapes are only supported in values, not in keys (at least in
> > > kconfig).  i'm not saying this is perfect, but your line of
> > > argumentation falls flat. ;)
> >
> > If you say so, it must be true! (Seriously, I can't follow your line
> > of argumentation.)
>
> keys don't support any escaping as of now. consequently adding more
> escaping is no "millimeter", as it would mean adding escaping in the
> first place.

Oh no, a function call!
That really changes everything. I mean, why do you bring irrelevant arguments?

> it might be not much effort to add, but interpreting any 
> escapes could definitely change the semantics of some existing keys.
>
Find me one. I didn' find any in my ~/.kde/share/config at least.

Backwards compatibility must be broken if you want to improve things, big 
deal. There is a system in place to deal with updating config files, and it 
is explicitly stated that an updated config file will not be readable by an 
older version of an application.
So minor versions may break config files, and you are arguing that major 
versions may not. Compatibility just does not seem to be that big an issue. 
Backslash escaping is also very unobtrusive if you don't make use it.

> > I am simply saying that forcing programmers to care *at all* about
> > what they pass to KConfigBase is bad. Covenience is, among other
> > things, not having to care.
>
> keys are traditionally thought of as identifiers (in the c++ sense) -
> i'm pretty sure this is what kalle was assuming when he wrote the code
>10 years ago. from here it really isn't much to think about ...
> 
Tradition is great for tourists and museums, and it has nothing to do with 
good API design.
You are acting like a museums' guard.

> > And who reads the desktop file spec before using KConfig, anyway?
>
> nobody. but arbitrary kconfig files are not supposed to be used as
> desktop files. and if you handle desktop files with kconfig (as opposed
> to kdesktopfile) you *really* should read the desktop entry spec.

Hey, that's true! Let's just separate the concept of config files and desktop 
file, while reusing as much implementation as possible.