[Development] qmlbundle vs Qt Resource System

[Thiago Macieira]

On terça-feira, 13 de agosto de 2013 12:40:20, Thomas Hartmann wrote:
> My conclusion would be to deprecate qmlbundle, since it is not really
> documented and supported (especially from the tooling side) and it does
> not seem to have any genuine advantage, while .qrc files and .rcc files
> have been part of Qt practically for ever and are supported by tooling.
[cut]

Sounds good.

> The only use case that came up, where .rcc should not be the solution,
> is a cache for the jit. I think any cache for the jit should go into a
> separate file and should not get mixed up with resource bundling.

If the cache is platform-independent and future-proof, I don't see why it 
couldn't be added to the bundle.

> Another topic that came up was qmldir. Since Qt 5 now supports to .json
> to describe and annotate a plugin, shouldn't we use this instead of
> another arbitrary file format? Of course we will continue support for
> qmldir, but we should depreciate it and use .json instead. Like for any
> other plugin in Qt.
> 
> The qmldir file could be replaced by qmldir.json in the pure .qml plugin
> case.

I disagree, somewhat. Please don't ask people to manually write JSON files in 
their text editors. But I can't say whether people often have to write those 
files and if they do it by hand or whether there are tools to do it. From what 
I can tell, they're usually very simple files and are easy to generate using 
shell tools. Therefore, I'd recommend they should stay as-is.

This is also one of the requirements I've made for the new config API: the 
actual config files should be plain text, preferably INI, but can be cached into 
(binary) JSON.

> If the plugin is converted to .rcc the .rcc file contains the
> qmldir.json file.

That sounds more like my config proposal: it's a cache, not the actual user--
modified file.

> > - qrc resources can be stored in separate files (.rcc), or embedded into
> > the executable. Qmlbundle files are always separate files (.bundle).
>
> True. While most people (including me) did not know about .rcc files,
> they are supported.

I didn't either.

And since I haven't done any investigation... please make sure what happens to 
the application once you load an arbitrary .rcc file. In particular, since 
resources may simply add to the root of the resource system's path, it may 
override assets that the host application needs, including those coming from 
Qt itself.

Should .rcc files be considered hostile, and an application should only load a 
trusted one?

> > - rcc can optionally compress the content (on by default).
> 
> If it does not already do this: rcc should not compress kwown image
> compressed formats by default (.jpg/.png).

It should compress and verify whether the compression result is worth it. If 
there's no gain, it should simply store uncompressed.

One of the advantages of storing uncompressed is that QFile::map() returns the 
actual pointer to the data.

> > - rcc always processes a .qrc file, while qmlbundle individually add /
> > remove /update files to a bundle by passing them on the command line.
> There was the idea to add similar functionality to rcc. Like any command
> line compression tool rcc then would take files and even (recursive)
> directories and convert them to .rcc files.

You're now describing a Zip file. If we're going to go anywhere there, why not 
use simply a Zip file?

> > - qmlbundle has 'metalinks' that you can use e.g. store stripped /
> > processed versions of individual files.
> Is this used? Couldn't this be solved by file endings instead?

Sounds like premature optimisation to me. A JIT cache sounds more interesting 
to me.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130813/7062d02b/attachment.sig>