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

[alan.alpert at nokia.com]

João Abecasis Wrote:
>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?

Definitely! I'm just confused about all the different approaches and how they relate. There's no need for a Settings API like this if the offline storage API is good enough (and it is not, and never will be so long as we try to copy the HTML standards). Similar with JsonDb. So we'll end up with someone wanting to store application data and they'll pick whichever they find in the docs first. Which would be really bad if the Settings API ends up gorgeous and they found offline storage first :( .

>What is the use case for JsonDb, anyway?

Beats me. I should ask them the same challenging questions of why anyone would use it when we're designing this great new Settings API ;) .

--
Alan Alpert