list separator in config entries

[Andreas Hartmetz]

2007/10/8, Andreas Pakulat <apaku at gmx.de>:
> On 08.10.07 08:09:26, Thomas Braxton wrote:
> > On 10/8/07, Oswald Buddenhagen <ossi at kde.org> wrote:
> > > On Mon, Oct 08, 2007 at 01:22:02PM +0200, Andreas Hartmetz wrote:
> > > > 2007/10/8, Oswald Buddenhagen <ossi at kde.org>:
> > > > > the question is at which point lists are serialized and therefore
> > > > > through how many escaping passes they go.
> > > > >
> > > > Ahem yes, I missed that.
> > > > You are arguing for another refactoring of KConfig here which I assume
> > > > was not your intention.
> > > >
> > > whoops. ;)
> > >
> > > > I agree that we need to fix things right,
> > > >
> > > exactly.
> > > if another refactoring is the price to pay, we need to bite the bullet.
> > > note that this is only internal stuff, so it doesn't necessarily mean a
> > > further delay.
> > >
> > > > For the record: The refactoring would consist of moving list handling
> > > > into the backend(s)
> > > >
> > > yes.
> > > given that the windows registry can handle numerical values and blobs,
> > > too, all of the type handling should move to the backends - the api
> > > would only know qvariant, which would allow arbitrarily complex nesting
> > > and leave complete freedom to the backend.
> > > to support backends that don't provide arbitrary binary storage (in
> > > particular, text-oriented backends like ini), a serialization
> > > class/namespace would be provided to share code.
> > > serializers for gui classes need to be somehow external ... hmmm,
> > > actually, this is a generic problem if custom data structures should be
> > > supported.
> > >
> > > > > assuming that the spec is implemented only by people who know
> > > > > anything about working escaping is pretty naive.
> > > > >
> > > > Programmers OTOH should know what they are doing.
> > > >
> > > the key is "should". particularly in the lesser known almost-one-man
> > > projects the know-how is often missing. it's incredible how much crap is
> > > out there. so it is crucial not to leave *anything* to interpretation in
> > > a spec.
> >
> > couldn't KConfigGroup just escape the escape chars, and if you want to
> > change KEntryMap, I don't really see a problem, but can't that wait until
> > after 4.0? It's not like we have any other backends right now.
>
> Uhm, we can't change the API after 4.0, so removing the custom-separator
> method is needed to be done _now_.
>
Fortunately, a random sampling of about 25 of lxr.kde.org's 170 hits
for "readEntry" didn't turn up one single user of custom separators.
It's totally silly, and API users seem to have realized it :)