[Development] Development Digest, Vol 99, Issue 17

[Arnaud Clère]

Hi,

Le lun. 9 déc. 2019 à 16:34, <development-request at qt-project.org> a écrit :
> > Should I go on creating a QTQAINFRA issue for that?
>
> You can create a QTQAINFRA ticket, although that will just help in it
> not being forgotten by the admins. The decision on creating the new repo
> happens here on the mailing list.

Yes, that is what I expect.

> > Name: QtDataTransforms ?
>
> That name is pretty abstract and just based on it I would have guessed
> in a completely wrong direction what the module is for.

Or maybe not (see below)

> You're talking about it as a serialization module even in the subject of
> this mail. Wouldn't QtSerialization be a natural name?

It would be the best name for the short term but it would miss the point.
The proposed API is abstract. It allows operating on any kind of data with
a structure similar to JSON. Serialization/deserialization is a special
case that reads or writes the data as contiguous bytes. But the same API
can also build generic data structures such as QVariant/List/Map,
QCborValue, QAbstractItemModel (= GUI, DB).

So the point is to make it easy to transform data from one "form" to
another, be it a file or C++ data structure. The API can support filtering,
complementing data, or adjusting its shape like when moving a Person {
QList<Person> children; } struct to a TreeView or TableView. In that
respect, it is similar to Python comprehensions or very simple XSLT
transforms.

Maybe "QtDataInterop" would better convey the goal to bridge specific
formats/APIs/modules with a very simple data model? You tell me...

So, anyone interested in playing with this?
Looking at the examples in the proof of concept just takes a few minutes
and I welcome any kind of feedback:
https://gricad-gitlab.univ-grenoble-alpes.fr/modmed/modmedLog/tree/master/tests/QBind#examples
I know some find it weird in a bad way. But some find it fun and useful
too, especially it it extends to new formats/APIs.
My priority is JSON/CBOR. What would be yours?

OTOH, anybody objecting me proposing something like that as a separate
module?

> I think I got the impression that actual users getting to see and use
this API is the goal. So likely being under qt/
> fulfills the purpose better.

You are right. The value of this module would be directly tied to the
number of its users/apps/formats.
I have little incentive to grow this out of qt/ namespace since we already
use a version of it internally at my company.

Thanks,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191209/55e52e10/attachment.html>