[Development] A QtCore class for event-driven jobs

[David Faure]

On Friday 06 September 2013 17:20:59 Thiago Macieira wrote:
> On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote:
> > * relation to QNetworkReply?
> > If that one didn't exist yet, we'd definitely write it as a QJob subclass.
> > So  instead, I propose to wrap QNetworkReply into a QNetworkJob or
> > something, in order to offer the QJob interface for QNAM requests. On one
> > hand this doesn't have to go in at the same time as QJob itself, but OTOH
> > it could be a real- world testcase for it, proving its usefulness and
> > correctness...
> > 
> > Any other questions?
> 
> What if we put the QJob class and convenience derived classes like
> QNetworkRequestJob, QProcessJob, QThreadJob, etc. in one new library.
> 
> This library could be extended later with more job types.

I understand that you want to limit the growth of QtCore, but, hmm, a separate 
library/module QtJobs seems very strange. It's not like it's separate 
technology, the core of QAbstractJob's technology is the QtCore event loop.
Can you see yourself at the next Dev Days presenting the Qt modules with
"Qt Core, Qt Gui, Qt Network, Qt Multimedia and ... Qt Jobs" ? It doesn't fit 
that list, because it's not a separate technology with separate dependencies.

In addition, this prevents using these job classes within Qt itself:
if QNetworkReply didn't exist yet, and if QAbstractJob was in QtCore already, 
then surely we'd call it QNetworkRequestJob and make it derive QAbstractJob, 
and we'd put that in QtNetwork. The only reason we got QNetworkReply instead 
is that QAbstractJob didn't exist yet.
By putting the jobs "on top of everything else", we will always have the 
QNetworkReply/QNetworkRequestJob redundancy everywhere a Qt API would benefit 
from returning a job class.

I still think the best solution is:
QtCore: QAbstractJob, and later QProcessJob and QThreadJob
QtNetwork: QNetworkRequestJob (wrapping QNetworkReply)
QtDBus: (later) QDBusCallJob (wrapping QDBusPendingCallWatcher)

The latter is another reason why a QtJobs library wouldn't work. In order to 
provide an async-dbus-call job, it would have to link to QDBus, forcing a 
QDBus dependency onto every user of core-only jobs like QThreadJob.

Looking at my initial email, I think that's all. There isn't going to be 20 
more job classes in qt itself, the only async operations that happen in there 
are all on top of sockets, processes and threads.
(and timers, but a QTimerJob isn't terribly useful ;)

-- 
David Faure | david.faure at kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions