<br><br><div><span class="gmail_quote">On 10/8/07, <b class="gmail_sendername">Oswald Buddenhagen</b> <<a href="mailto:ossi@kde.org">ossi@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

On Mon, Oct 08, 2007 at 01:22:02PM +0200, Andreas Hartmetz wrote:<br>> 2007/10/8, Oswald Buddenhagen <<a href="mailto:ossi@kde.org">ossi@kde.org</a>>:<br>> > the question is at which point lists are serialized and therefore

<br>> > through how many escaping passes they go.<br>> ><br>> Ahem yes, I missed that.<br>> You are arguing for another refactoring of KConfig here which I assume<br>> was not your intention.<br>><br>

whoops. ;)<br><br>> I agree that we need to fix things right,<br>><br>exactly.<br>if another refactoring is the price to pay, we need to bite the bullet.<br>note that this is only internal stuff, so it doesn't necessarily mean a

<br>further delay.<br><br>> For the record: The refactoring would consist of moving list handling<br>> into the backend(s)<br>><br>yes.<br>given that the windows registry can handle numerical values and blobs,<br>

too, all of the type handling should move to the backends - the api<br>would only know qvariant, which would allow arbitrarily complex nesting<br>and leave complete freedom to the backend.<br>to support backends that don't provide arbitrary binary storage (in

<br>particular, text-oriented backends like ini), a serialization<br>class/namespace would be provided to share code.<br>serializers for gui classes need to be somehow external ... hmmm,<br>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.

<br>><br>the key is "should". particularly in the lesser known almost-one-man<br>projects the know-how is often missing. it's incredible how much crap is<br>out there. so it is crucial not to leave *anything* to interpretation in

<br>a spec.</blockquote><div><br class="webkit-block-placeholder"></div><div>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. </div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><br> </div>