RFC: escape strings in KConfigBase

[Andreas Hartmetz]

On Wednesday 16 May 2007 04:41:10 Michael Pyne wrote:
> On Tuesday 15 May 2007, Andreas Hartmetz wrote:
> > 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.
>
> I'm worried at all the talk being bandied about disparaging backward
> compatibility.  Backward compatibility is a *good* thing, except when it
> becomes responsible for bad code.
>
> In this situation we'll have to retain some form of backward compatibility
> anyways for kdeglobals so it may be easier to branch off another subclass
> with the proper escaping semantics, and mark the old class as usable with
> keys/values meeting criteria to where they do not require escaping.
>
This is probably the best way to do this - an old compatibility version and a 
new "takes any string" version. The new version could be just a wrapper 
around the old one for KDE 4, to have a chance to get it done at all in the 
time that is left.

> But backward compatibility is something we as developers (and especially
> *library* developers) must strive to maintain.  It's the difference between
> newly-upgraded software working right the first time and retaining all of a
> user's old settings, and software that must be reconfigured all over again.
> Or being able to add functionality to a library without breaking
> applications that already use it (which I think we just normally refer to
> as binary compatibility but this is more restrictive).
>
> > > 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.
>
> As Oswald pointed out, just because your ~/.kde/share/config is fine
> doesn't mean that no one out there has a config directory that is fine, and
> will continue to have a suitable configuration until they upgrade.  And
> Ingo already provided a counterexample.  Again, the burden is hard on the
> library implementer in this situation, as when you change the semantics of
> library code the fact that nothing on the dev's system will break is no
> excuse for breaking someone else's system.
>
> > 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.
>
> True, (but don't forget about kdeglobals).  I would argue that it would be
> difficult to develop and completely debug a script to properly escape KDE 3
> config files and at the same time avoid escaping already-converted KDE 4
> files.  Not to mention the time to mass convert all of the config files
> (although admittedly it's only a one time cost).
>
> > So minor versions may break config files, and you are arguing that major
> > versions may not.
>
> Minor versions do not break the encoding of config files.  You could still
> correctly read newer config files with older kdelibs, but the older
> application would not necessarily understand some of the options and
> settings.
>
> The only real problem I see with your proposal is that it also seems to
> engender losing the ability to properly read old config files (i.e.
> unescaping files by accident that were never escaped).
>
OK, see above. Two versions or a "compatibility mode" flag [set by default -> 
source compatible], not sure yet what's better or more doable in limited 
time.

> > > 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.
>
> And at the same time do not reject something merely because it is
> traditional. Those traditions which can be justified we maintain, those
> that are wrong we try to eliminate.  At least, in an ideal world.
>
Ah, I certainly don't want to change stuff for the sake of changing it.
My point was that "It's always been done that way" alone is a weak argument.

> Regards,
>  - Michael Pyne