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 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
