[Development] QConfig update.

[Oswald Buddenhagen]

On Tue, Oct 14, 2014 at 07:06:30PM +0200, Milian Wolff wrote:
> On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote:
> > On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff <milian.wolff at kdab.com> wrote:
> > > On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote:
> > > > it has a QConfigGroup 'global' value that can be acced directly via
> > > > .setValue and .value
> > > 
> > > Why the global state? A QConfig should be valid for a single file and
> > > constructed on-demand. If you want to share stuff and keep it open, adding
> > > something like a KSharedConfig might be a good idea. But again, that is
> > > something that could/should be built on-top of QConfig (imo).
> > 
> > so I don't need to open a config file and parse it every time the user
> > created a QConfig object.
> 
> Then provide a QSharedConfig or let the user store the QConfig himself, if it 
> turns out to be a performance-bottleneck for him.
>
as i previously pointed out, this is one of the things i consider *bad*
about kconfig.
i wouldn't necessarily make a real cache, but the objects should be
automatically shared in the background. that's what happens when you
natively use the windows registry anyway.

> If you add global state to QConfig, you'll need synchronization or
> otherwise you are doomed in a multithreaded application.
> 
yes. so what?

> Furthermore: If you keep the QConfig in memory all the time, you'll probably 
> end up duplicating the stuff as soon as you add the fancy high-level interface 
> on-top. QConfig will operate on JSON after all and you'll incur a conversion 
> penalty whenever you read a value from it. The high-level interface should 
> (hopefully) read the values once and store it internally in the proper type. 
>
you are right with that (that's why i don't think using the json classes
as anything else than backend storage and having an abstraction layer on
top makes sense), but i don't see how that correlates with the config
objects being shared+cached.