[Development] qmlbundle vs Qt Resource System

[Oswald Buddenhagen]

On Tue, Aug 13, 2013 at 09:32:08AM -0700, Alan Alpert wrote:
> On Tue, Aug 13, 2013 at 8:47 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > On terça-feira, 13 de agosto de 2013 12:40:20, Thomas Hartmann wrote:
> >> 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.
> 
> It needs to be part of the bundle, platform-independent or not. Part
> of the qmlbundle plan was that you have a single file you can mmap in
> to get the result of the compilation phase with maximum efficiency.
> Part of the long-term QML plan is to JIT ahead of time, during the
> build phase, and to even extend that to the QML parts (not just JS
> snippets). If .rcc can't handle platform-dependent files then we'll
> need to go with qmlbundle (or we fix QRC until it does, has anyone
> investigated that?).
> 
these considerations seem irrelevant to me.
if you do AOT compilation into a platform-specific format, the correct
solution is to compile it into a proper binary (which would typically
also contain the compiled qrc data).
when you then have a platform which supports multiple variants in one
bundle (e.g., android and osx), you'd do that bundling at the os level.
in either case there is no point in having multi-platform support in the
qrc system.

> >> 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.
> 
> Note that, outside Qt, the pure .qml (or mixed) case is more common I
> believe than the "just a C++ plugin" case.
> 
> The other issue (possibly solvable) is that QML modules are always
> defined by a qmldir file, not a plugin, which would lead to a lot of
> issues (recognizing modules, finding the plugin in order to load the
> metadata file) if we tried to move the functionality into the new JSON
> metadata files.
> 
yes, this issue must be solved.
there are exactly two cases:
- interpreted qml only. in this case you can package up the whole thing
  into an rcc file and include the qmldir there - opening it is cheap.
- anything platform specific (plugin code or just precompiled qml). in
  this case you comple a proper plugin (and any plain qml and other data
  is included via qrc into the binary). you cannot reasonably compile
  the qmldir into the plugin, because opening it just to check what is
  in that plugin would be prohibitively expensive. ergo the qmldir needs
  to be transformed into the new-style json-based plugin meta data. note
  that it is entirely possible to make that an automatic build-time
  step, so there is no need to drop qmldir as such.
  currently the qmldir also contains the plugin name to load. this must
  be changed, because it's a) counter to the atomic bundle (one file)
  idea and b) it's meaningless in case of statically linked plugins. see
  the discussion in the relevant reviews.