[Development] qmlbundle vs Qt Resource System

[Alan Alpert]

On Tue, Aug 13, 2013 at 11:42 AM, Oswald Buddenhagen
<oswald.buddenhagen at digia.com> wrote:
> 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).

That's what we're talking about - except that the binary may not
contain a native main in the case of a QML only entry point.

> 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.

So we'd have a cross-platform API (possibly just the build system),
which developers use but internally is just the platform-specific
method of bundling architecture variants?

>> >> 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.

I'm not following you here. In both cases there's a second file
outside the plugin, it's contains the same data, why does it have to
be JSON?

This plugin is not loaded like the other Qt plugins, it's loaded via a
different path triggered when the QML engine reaches an import
statement. The import statement points to a specific directory, we
need a specific file in that directory to be or point to the plugin
and the plugin meta data files don't fulfill that usecase (yet, I
suppose they could be extended?).

>   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

The important thing about the atomic bundle idea is that the number of
files is O(1), not 1 specifically. But if we had everything in one
bundle, we would make that the module target instead of qmldir in the
compiled case.

>  and b) it's meaningless in case of statically linked plugins. see
>   the discussion in the relevant reviews.

That's a separate issue, qmldir is already meaningless for statically
linked plugins but having a different target in URL based module
imports isn't going to help (we need non-url based module imports).

Other cases that come to mind:
- Interpreted QML over network: Downloading the extra files (including
all image assets) and opening it is prohibitively expensive - we
probably won't support AOT/JIT in these cases though so that might not
use bundles.
- Modules compiled into an application: Where qmldir files are used
inside an application when the application is compiled and so can be
stripped out entirely from the build product (except for the compiled
cache) without any JSON/plugin involved.

--
Alan Alpert