QML-using app developers: use private.* imports

[Sebastian Kügler]

Hola,

On Thursday, September 26, 2013 02:23:31 Aleix Pol wrote:
> Reducing API to maintain is a good thing, at least for complexity sake. But
> of course there will be always the case where somebody needs (part of) the
> private API.
> 
> The question would be then, why is it that there's some API that's only
> needed for internal usage? If it's needed internally, it will be most
> likely needed externally, at some point. The fact that you decide to label
> it as private makes frustrated developers.
> 
> Either way, I have no idea of what we're talking about here. :D

It's not a question of usefulness, it's a question of maintainability. We 
offer some basic functionality

If / when a private import is needed, there's a bunch of things to solve. 
Dependencies, documentation and very important API stability. For public APIs, 
we definitely want to offer API stability, but it doesn't make sense for 
everything, so by making these imports private, we keep the flexibility to 
develop them however we want, otherwise, we quickly end up with a huge bunch 
of code that we need to maintain backwards compatibility for, just in case 
someone else wants to use this, often highly specific, code. Also outside of 
the C++ world, you don't want to install all apps' internal bits and pieces as 
system-wide available libraries. We want to make it easy to extend QML apps, 
plasmoids, etc. using C++, but without the costs of public libraries.

This isn't to say that these things will not ever be shared, if something 
turns out to be very useful for more than one Plasmoid, for example, we can 
still promote it to public API, with all the costs that incurs. They just need 
to weigh up against the work we need to put into it, and someone actually has 
to do the effort, bring it up to "library quality" and maintain it.

Another very important aspect is security. We eventually want to arrive in a 
world, where QML apps can only use imports they are allowed to. You most 
definitely don't want a random piece of QML to access models of your Akonadi 
db, Nepomuk, do random file-system stuff, etc.. Using the new-in-Qt5.2 
QUrlInterceptor in the scriptengine allows us to control what's accessed from 
within the QML runtime. This is described in detail on 
http://community.kde.org/Plasma/conditionalQMLImports and the result of design 
done during Akademy / QtCS in Bilbao. Pretty cool stuff, actually. :)

Examples for private imports are Kickoff-internal models, sytemtray models and 
items, KIO and mimetype tricks for showing icons on the desktop. Apply the 
same idea to Kontact Touch's QML imports, to Telepathy's, etc. It all makes 
sense!

Lastly, we are responsible for our APIs not becoming a random mess. This is 
one measure to prevent that from happening. Focus and quality usually trumps 
size.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9