[Development] A QtCore class for event-driven jobs

[David Faure]

On Saturday 07 September 2013 00:55:26 Konstantin Ritt wrote:
> Simply can not ignore this thread :)
> Like Andre, I have written my own jobs implementation, too.
> And I completely agree that not having some kind of job manager makes QJob
> API of quite limited usefulness 

I disagree. One can choose to associate jobs with some sort of manager, but 
that manager will always be framework-specific, so this can be done in the 
frameworks themselves. Examples: KIO associates jobs with a singleton 
scheduler. Akonadi associates jobs with an imap session by passing a parameter 
to the constructors. All of this doesn't affect the basic job class.

> Plz don't forget that some generic API in Qt, i.e. like async jobs, should
> be flexible enough to be used for quite different tasks by variety of
> users

Exactly. This is why it should be usable with and without a job manager".

> , not only just to make a "standard base" in future KIO implementation.

This is about much more than KIO, my initial email had a list of existing use 
cases.

> job =  someoperation(some parameters);

Yes, you can of course have factory methods in your framework.
Just like QNAM::get/put/post. But surely that doesn't mean QtCore (QJob) 
itself needs to have the concept of a job manager. We'd have two then...

> manager->enqueue(job);

The job's start implementation can do the enqueuing.

> This way, job not necessarily should derive from QObject; all required
> signals and methods could be provided by some kind of job watcher [or job
> sequence watcher] or even by the manager itself.

I don't see what's gained by that.

> Moreover, in case where one needs i.e. to visualize jobs sequence execution
> progress with just a single progressbar, having to connect to every job's
> progress/finished/error/whatever signals and/or suspend/resume/abort slots
> once the job is started makes the implementation not really convenient to
> the user. Connecting to the manager just once looks like a better option
> for a generic case, IMO.

A manager implies ownership, which isn't desired.
But this can be done in a different similar way. I omitted from my initial 
description an additional feature we have in KJob, which is "job trackers".
Each job can be associated with a tracker interface, which is basically the 
base class for something that displays job progress.
I thought this could be omitted, because it's something that sits on top of 
QJob (if we replace job->setTracker with tracker->addJob(), so that job isn't 
tied to tracker).
Then in your own framework, you can decide if you want a global tracker for 
all jobs, or one per job or per type of job, or depending on the window that 
created it (because each window has a different embedded progressbar)...
But none of that logic has to be in QJob, so that it stays more flexible.

The main difference I see between trackers and managers is that for simple 
cases you can do without a tracker, while a manager would be mandatory in all 
cases -- which is unnecessary overhead.

> Another major possible obstacle is a need to suspend job execution up until
> some additional info has taken from the user (i.e. proxy authorization,
> non-critical errors handling/reaction, etc.).
> In common case, this requires appearing some dialog in GUI thread and thus
> a making blocking call to some user-defined callback, if any (and possibly
> job re-execution after a successive call,  e.g. "re-try with admin
> privileges", where re-enqueuing is definitely not an option). There could
> be more elegant solution but still, implementation must not force the user
> to re-invent a wheel every time he needs it.

To be clear: suspend() is from the outside, while this is about the job itself 
needing to pop up a dialog. KIO's jobs already do that just fine. It's the 
same job going on, the dialog is just an additional step, it can take care of 
re-enqueuing into its own execution manager if that's needed.
I'm not saying some frameworks won't have some sort of manager object.
I'm saying it doesn't need to be part of the common API, since it's framework-
specific.

-- 
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