Binary QML compilation...

[raulgd]

Does anyone know whatever happened to compiling QML text files as binaries so that developers can protect their intellectual property, improve loading performance, etc?

Here's the reference on binary QML from this forums, which according to it, shouldn't be hard to add to Qt:

"Protection of QML code":http://qt-project.org/forums/viewthread/16693/#84245

So, any Qt developers that could tell us if this could come as a feature in Qt 5?

Thanks!

[andre]

The important part is the
[quote]
but noone has come around to it[/quote]

AFAIK, that is still the current status. Perhaps you did notice that there have been some changes at Nokia too in the meantime, including closing of the Brisbane office where a lot Quick was developed.

[raulgd]

Yeah, it was a really sad day for me when I found out that the Brisbane office was being closed, there were some really talented engineers working there and were adding a lot of cool stuff to Quick.

well, I guess that's that, no binary QML until further notice.

I would contribute, but I'm not familiar enough with the Qt source code... I peeked at some stuff once (the network library) trying to understand some async handling, but it was like reading APL code, there's some really black voodoo under the covers, and I feel that the documentation is lacking on how the core works.

Also, if there was a way to find out where that part of the code was being worked, maybe we can all do our part and try to finish it up, according to the post, the code is done, and the part that needs to be finished is the build process.

[lgeyer]

If you really want to work on this just pop in at #qt-labs or development@qt-project.org; people will be more the willingly to help you.

[raulgd]

I can't go into #qt-labs because the proxy at work has all IRC access blocked, so I'll have to check how to subscribe to development@qt-project.org and ask around

[twsimpson]

freenode listens on ports 6665, 6666, 6667, 6697 (SSL only), 7000 (SSL only), 7070 (SSL only), 8000, 8001 and 8002, so perhaps you can get around the proxy with one of those ports. ref: http://www.freenode.net/irc_servers.shtml

[twsimpson]

oh, there's also webchat: http://webchat.freenode.net/ which should tunnel everything over http

[raulgd]

nope,

Other ports don't work, as it's a web proxy, so only 80 and 443 are open. And the webchat.freenode.net is blocked.

I really hate web coat proxies, I feel like a f*cking kid being supervised when doing my homework, but hey, it's the only job available at the moment

[twsimpson]

well, in case you haven't found it yet, you can subscribe to the mailing list from http://lists.qt-project.org/mailman/listinfo/development

[raulgd]

thanks!

Actually I was about to look for it

[andre]

It's probably not a great idea trying to circumvent company filtering of the internet anyway. I know it's a bitch to work with (learned my lesson on my previous job for not checking on that before I came to work there), but actively trying to get around one may jeapardize your job. If you feel treated like a kid there, first try to convince management to lift the restrictions, at least for the developers (explaining that they are blocking useful resources that can help you be more effective), and if that doesn't work: find another job that does treat you like an adult.

[sierdzio]

As a workaround, you can use QRC to build your QML code into the binary.

Internally, QML is compiled into binary data, as this KDAB post neatly explains: "link":http://www.kdab.com/qml-engine-internals-part-1-qml-file-loading/.

[raulgd]

Thanks for the link @sierdzio

But as you can see on the link I posted at the beginning of this thread, there is already code implemented by the trolls to achieve QML binary compilation.

The only thing that it says is missing, is the integration into the build system so that when you build an application that has QML code, to be able to transparently compile/deploy without having to do anything funny.

The thing is, we have no idea where that code is, or where to start to find out how to finish up on that work.

[bkamps]

Anybody has a hint where this code can be found? Binary QML would be perfect (for me ;-))

[raulgd]

No sorry, I didn't get any response from the mailing lists, and haven't found it myself either, I'll post anything as soon as I know something.

[bkamps]

Are you also having QML performance issues? The parsing/compiling just takes too long on my platform for relative simple QML files...

[raulgd]

Not really, but that depends on many factors, from the way you write your scripts, if you have bindings between QML and C++, etc.

But I guess that's a topic for a different forum thread, you should ask on the Qt Quick forums

[mlong]

I've been looking at this as well lately, but also don't have anything solid to report.

[lgeyer]

[quote author="Raul" date="1348255816"]I didn't get any response from the mailing lists...[/quote]

Can you link to the thread? I must have missed it.

[chriadam]

Hi,

It's not quite as simple as Alan said in his original post in that poll thread, unfortunately.
There are a couple of issues.

The first is obvious: pointers. The current QML compiler produces compiled data which includes pointers (to type/property caches which can be used to generate QMetaObjects when required), and possibly other things (it's been a few weeks since I looked at the code, and my memory is getting fuzzy already ;-)

Obviously, this would need to change, to using an integer ID, or some other hash key.

The second is less obvious: mmapability. If the compiler output isn't directly mmapable, but instead write it out as some structure which can be read in via QIODevice, you'd probably actually lose time, since it's so inefficient. If it is mmapable, that'd be magic - but then you have platform specificness creeping into your code. That's not a problem (indeed, with the Bundle support that was added to QtQuick2, it's possible that in the future, application developers could provide per-platform precompiled typedata in the bundle, which could be mmaped in as required instead of a compilation step).

In the end, it's certainly possible to implement, but no-one has, yet. It's a fair bit of work to get right, in my opinion - and it's the sort of thing that you really want to get right the first time.

Also, instantiation will, in any event, dominate parsing/compilation in any performance benchmarks, I think.

Cheers,
Chris.

[raulgd]

Ok Chris, thanks for giving us a more detailed answer about this subject.

But then, as far as you know as a troll, is anyone out there considering giving us an out-of-the-box way to protect our QML for distribution instead of just simple qrc bundling which can easily be circumvented? Or is that something that no one hasn't even actually considered?

One of the advantages of Qt is not only portability and performance, but the fact that you actually get compiled code as well, there are many other good, multi platform frameworks, but most of them are like java or .NET, so the code can be easily decompiled, and if you have code you want to protect because of security or IP, then the best way is to compile.

[andre]

If security is your main concern, then I suggest that you might make it harder for attackers by encrypting the QML before including in your resource. Sure, because you need to include the decryption key in your application, it can still be taken out, but at least the QML won't be there for everybody to see too easily, and standard tools won't extract anything useful.

Compiled QML also isn't a guarantee that it won't be broken with a decompiler. There is only so much you can do...

[raulgd]

yes you're right, the only warranty for protected code is compiled one... maybe I'll figure something out, like do draw calculations in C++ and leave only dumb rendering in QML so that way, if someone extracts the code, there won't be any really useful code there.

Thanks Andre

[chriadam]

Hi Raul,

I'm not actually a Troll any more, unfortunately. I don't know why that badge remains on my profile, I'll have to ask to have it removed. Regarding the "out of the box" possibility, well, it's entirely possible (eg, through encrypted sections of the bundle, or something, I guess - although I don't know how such a system would work) but I'm personally not aware of any such efforts. But as I said, I'm not a troll any more, and am not involved in those sort of feature discussions at this point in time, so my knowledge or lack of it shouldn't imply that it is or isn't happening, internally in Digia.

Cheers,
Chris.

[Troll badge removed, cheers -MariusG]

[Jens]

In case someone stumbles across this thread, it might be marked as solved as the Qt Quick Compiler is now an integrated part of the Qt 5.3 enterprise editions.