Jason H wrote:
> I like the idea, however I would probably have used XPath or
> http://docs.persvr.org/documentation/jsonquery
> I also don't understand why the QML db API is enough?
The db API can be used to persist configuration data. However, it doesn't imply
that it is configuration data. The idea here is to provide a generic API that
application developers can easily use to save/restore settings.
I also want to keep the door open for pure C++ and hybrid C++/QML applications
to access the same data. Ideally, the core functionality will live in Qt Core
and provide a pretty API for QML apps to hook into. (Obviously, a pretty API
will also be desired in C++)
> and done something like:
> Rect {
>
> width: xpathquery(storage, "/" + id + "/width");
>
> }
> Storage {
> id:storage
> source: "sample.db"
>
> }
This does not convey how data is propagated back to the database, or it would
require hacking the language to support it.
> I'd throw a curve out there to you and say with source, you can do
> "http://some.site.com/";, and supply account credentials.
> Implement a lightweight HTTP server and have persistent remote settings
> storage :-)
I'm not trying to provide generic file operations or RPC-like functionality.
Just plain-old what-QSettings-is-meant-to-be-without-actually-being-QSettings.
How this is mapped to physical memory, if at all, should be a decision for the
platform.
Potentially, a web browser supporting web QML apps could decide to map settings
to a local SQLite database or somewhere else in the cloud. As a "platform",
that browser should be able to provide its own backend, but we're not that far
along yet ;-)
Cheers,
João
_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
