[Development] A QtCore class for event-driven jobs

[Konstantin Ritt]

2013/9/9 Sune Vuorela <nospam at vuorela.dk>

> The api has been stabilized and well tested since like forever.
>
> Let's get a QAbstractJob heavily inspired by KJob in now.
>
> A nice side effect of getting it in now is that the myriad of nice
> frameworks KDE is preparing for ship could be built on QAbstractJob and
> KDE could skip shipping KJob and move everything over to QAbstractJob
> now and not after we in KDE has made our first release where we promise
> to keep ABI and API stability.
>
>
That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can
use it by only linking to QtCore.
Once released, it's API become frozen up until 6.0...and you don't really
care about all others who may disagree with it's design or simply can not
use it due to it's limited API and so on.
All I've seen so far (following by David's links) is a piece of KIO where
some API is still hardcoded to be used by KIO. I'd say this is not a 5.2
material at all.

Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or
usable drafts at very least.
Until then, I'm all in doubts about how useful would that be to the user.
In example, David said job's doStart() enqueues the runnable in the thread
pool; now looking at the code - it seems like we could have then
"started()" signal emitted, say, 5 seconds earlier than the runnable gets
dequeued and executed. So `for (int i = 0; i < 100; ++i) (job =
someoperation(params))->start();` gives us 100 "started" jobs where only
few of them got dequeued and really started; and thus all other jobs can
not report their actual execution state change because they were "started"
and become "started", once dequeued by worker thread...weird, isn't it?

First of all, put the initial implementation to Qt-project as a module.
Let's then gather such a use-cases and see where the current API is not
sufficient, then polish the API to make QJob usable in all those cases;
let's write some QJob-s based demonstration framework and polish the API
once again, if needed... and only then we'll see if it is good enough for
QtCore.

Kind regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130910/7b5bfc91/attachment.html>