RFC: escape strings in KConfigBase

[Michael Pyne]

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.

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).

> > 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.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070515/14374ae3/attachment.sig>