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.fa...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development