[Development] A QtCore class for event-driven jobs

[Knoll Lars]

Full agreement with Konstantin. It's two weeks before the feature freeze and we haven't seen any more then a draft. I am against any new classes going into Qt essential modules that do not have direct and proven use cases.

Develop it in a playground project, show why it makes sense and once you have a stable API let's discuss into which module it should go.

Cheers,
Lars

From: Konstantin Ritt <ritt.ks at gmail.com<mailto:ritt.ks at gmail.com>>
Date: tirsdag 10. september 2013 00:40
To: "development at qt-project.org<mailto:development at qt-project.org>" <development at qt-project.org<mailto:development at qt-project.org>>
Subject: Re: [Development] A QtCore class for event-driven jobs


2013/9/9 Sune Vuorela <nospam at vuorela.dk<mailto: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/153f9d79/attachment.html>