[Development] qmlbundle vs Qt Resource System

[Chris Adams]

Hi,

On Sat, Aug 10, 2013 at 6:05 AM, André Pönitz <
andre.poenitz at mathematik.tu-chemnitz.de> wrote:

> On Thu, Aug 08, 2013 at 08:18:00PM +0200, Olivier Goffart wrote:
> > On Thursday 08 August 2013 08:59:26 Alan Alpert wrote:
> > > I don't know specifically about why it wasn't built on top of QRC, but
> > > my guess is the performance cost. qmlbundle is more intended as a
> > > performance optimization for deployed applications than a deployment
> > > optimization, unlike QRC which just happens to make some deployed apps
> > > faster.
> >
> > My wild impression would be that it is just the NIH syndrome, as with
> many
> > other things inside the core of QML.
>
> This was pretty much my first thought, too.
>

> > If QRC was not fast enough, it could most likely have been improved with
> very
> > little changes to fit the requirement. They could have improved it, or
> asked
> > for it to be improved. We are in the same team, are we not?
>
> Whether it would have been feasible, or not, I don't know.
>
> However, what I do know for sure is that nobody ever tried to come up with
> a set of requirements and discuss the topic with the rcc maintainer.
>

I don't know too much about the specifics of the qmlbundle implementation
at all, but I do know at least some of the requirements which drove its
development.  As to whether or not qrc would have worked for these
use-cases is a different question (and one which I also know next to
nothing about, so I'm not trying to answer the "why wasn't qrc used"
question at all here).  But some of the things are:

1) Since a QML module can consist of just qmldir + .qml documents + .js
resources, we can't require a plugin or executable into which the bundle
gets embedded, to exist at distribution time
2) Going forward, including the compiled QML typedata into the bundle as a
two-stage build step was a goal.  This would greatly speed up application
startup time for obvious reasons (no need to parse the bundled .qml files,
no need to compile the parsed tree, just mmap the compiled typedata and do
the fixups for the virtual address offsets, etc).


>
> The whole resource code (core + the rcc commandline tool) is barely 3000
> lines of code. Might be not the nicest, nor the most obvious code ever, but
> field-proven, and "just works". Someone might even be able to look at it
> and find out.
>

> <sarcasm> But why bother when re-inventing wheels is so much more fun.
> And of course, the few thousand more lines of qrc tooling integration is
> nothing to be concerned of, either. It will magically adjust itself,
> at no cost. As usual. </sarcasm>
>

> The refusal to even only consider re-use of existing assets is a huge sink
> of resources.
>

It's not about fun, in many cases, it's about pragmatism.  I don't know the
reasons why Aaron and Roberto chose to implement it the way they did, but I
think it's wrong to believe that they did so out of some obscure desire to
be perverse or waste their own time on something which was already done.  I
do agree that if there was no communication between those involved and the
maintainers of qrc, then yes, that's something which definitely could have
been improved.  But don't assume that they didn't consider re-using the
existing asset; perhaps they looked at it and decided that it would be
better to implement something specifically tailored to the use-case that
needed to be solved.  Maybe they were wrong - that's entirely possible.

Cheers,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130812/68a344a8/attachment.html>