[Qt-qml] Settings / State Saving proposal for QML

[João Abecasis]

On Nov 23, 2011, at 2:54 AM, Alan Alpert wrote:
> On Tue, 22 Nov 2011 08:58:04 ext Alan Alpert wrote:
>>>> Do you have any more
>>>> concrete examples though? Should SameGame/Snake switch to this for
>>>> storing its highscores, or is this meant for simpler data (and they
>>>> should stick to offline storage)?
>>> 
>>> I don't have more concrete examples, as I just began exploring the
>>> problem space. That said, I'd want this to scale beyond just "simpler
>>> data". If SameGame/Snake can't be cleanly mapped with a Settings API, I
>>> say that doesn't bode well for the API.
>> 
>> That depends. The tabular data of high scores has a different format and
>> requirements to persisting x/y/w/h on an object.  I certainly wouldn't use
>> QSettings to store that data - but we've established this isn't a QSettings
>> clone ;) . What is an example of data too large or complex for you to want
>> this API to cover? Or does it do *EVERYTHING*?
> 
> On that point, the jsondb api discussion said they could do Samegame 
> highscores with their API too ;). So I'd like to add the further question: 
> Where's the boundary between when you'd use Settings and when you'd use 
> JsonDb? Some grey area, where either would work, might be inevitable but they 
> need several clearly distinct usecases to make it worth adding both.

I'm assuming here that there is a use case for storing application-specific configuration data in a platform agnostic way. The Settings API is not supposed to replace a database if you need more advanced queries and processing.

We could potentially envision a platform where JsonDb is the central store for such application-specific configuration data. In such a platform Settings should interface to JsonDb, hopefully offering a simpler, more convenient and portable API for application developers that are not using JsonDb-specific features.

Alternately, JsonDb could offer its own Settings-like API for those developers who just don't care.

But it goes back to my assumption about there being a use case for storing (yes, and loading) application-specific configuration data. Do we agree on this?

What is the use case for JsonDb, anyway?

Cheers,


João