[Development] New repo as playground for potential "serialization" module?

[Kari Oikarinen]

On 6.12.2019 19.36, Arnaud Clère wrote:
> Hi,
> 
> Thiago suggested below that I submit my API proposal for serialization
> outside of QtCore to see whether it makes sense.
> I understood it would require a new repo as a playground for a kind of
> "preview" module.
> 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. There is some hope in admins
remembering to create the repository based on just the mailing list
thread.

> See details below.
> 
> Thanks,
> Arnaud
> 
> ---------- Forwarded message ---------
> De : Arnaud Clère <arnaud.clere at moulinarso.fr>
> Date: jeu. 28 nov. 2019 à 13:25
> Subject: Re: [Development] FW: QtCS19 Serialization session
> To: <development at qt-project.org>
> 
> -----Original Message-----
> From: Thiago Macieira <thiago.macieira at intel.com>
>>
>> Would it make sense if this API were not in QtCore?
>> Then we could give it a try and see how many people think it's useful, what its pitfalls are, etc.
> 
> Yes, it is possible and it perfectly makes sense. It does not have to
> wait for Qt6 too.
> 
> It only implies to duplicate a CBOR stream writer but the new one
> would have the opportunity to distinct QByteArray containing binary
> data from those explicitly containing utf8 data for better
> performance. The existing QCborStreamReader can be used from the
> outside as performance is not so critical for reading.
> 
> At one point, my longer term goal of providing a structured logging
> facility compatible with QDebug could bring back the subject to move a
> few things back to QtCore but maybe not.
> 
> How do I proceed? I guess I need to ask for a specific repo as described here:
> https://wiki.qt.io/Requesting_New_Repositories
> 
> 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.

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

> 
> Description:
> QtDataTransforms long-term goal is to make it easy to move data
> to/from specific Qt modules based on a common JSON-like data model
> made of sequences, records, and basic data types. It defines a default
> view of most Qt types following their equivalent QML definitions. It
> is designed to support all of JSON and CBOR formats,
> as well as in-memory data structures like QJsonValue, QCborValue or
> QVariantList/Map. It aims to support more elaborate data models such
> as CSV, XML, and  QAbstractItemModel using optional metadata to allow,
> for instance, reading a CSV file to a TableView in a single line of
> code, writing a TreeView in XML format, etc.
> 
> Responsible persons: me and/or ? Who would be reviewing it?
> Desired repository name: qtdatatransforms ?
> Namespace: QtDataTransforms ? Is it possible to keep a few things in
> Qt namespace ?

The namespace talked about on the wiki page is not a C++ namespace. It's
the namespace in the repository name on Gerrit. So qt like in qt/qtbase
or playground like in playground/qtjsonstream.

But the right namespace here is a good question. Wiki says:

<start quote>
   - All projects which are meant to ultimately end up in the qt
     distribution should start out in the qt/ namespace.
   - The playground/ namespace is for projects which don't fit any
     other category.
<end quote>

This sounds like it could belong in the qt/ namespace if it aspires to
be an actual Qt module included in releases. Or released separately but
a first-class part of Qt.

If this is supposed to be just a working area for a prototype before
later inclusion for the ultimate product in qtbase, then maybe
playground/ is a better fit. But in that case it could be just a feature
branch in qt/qtbase. 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.

-- 
Kari