[Kde-pim] Async feedback

[Christian Mollekopf]

Hey Daniel,

I meanwhile took a look at the async code, and here's the feedback I have so 
far.

First off though, nice job! I think it goes very much in the right direction 
=)

So:
* I think it would be nice to remove waitForFinished from FutureGeneric, 
offering only a callback. It keeps the baseclass simple and clean, and it's 
easy to implement a little wrapper that provides blocking waiting if 
necessary.

* Currently you're copying all result values to pass it on to the next step, 
which is something I hoped to avoid. I think setFinished should take the value 
and directly call the continuation (should be possible from what I've seen).

* The final value should be consumable by a continuation:

job.exec().then<QString>(
	//final continuation consuming the value
)

The continuation would in this case also replace the FutureBase::isFinished 
acessor I think.


If you wanted a future that stores the value you still could:
MemoryFuture<QString> finalFuture(future2);

The memory future would internally copy the value from the continuation, 
perhaps emit a signal when done, and provide isFinished().

* We may want to add support for more convenient composition:

getJob1().then(getJob2())

Currently you have to do something like:

getJob1().then([this](const QString &arg, Async::Future<void> &future) {
  getJob2().exec().then<void>([future]() {
		future.setDone();
	}
});

Which is fine for now and works nicely with kjobs, but perhaps it would be 
worth it to improve on that sometime? Of course the convenient composition as 
above would only work if the result type of the first job and the argument 
type of the second job are a perfect match, so perhaps it's also not worth it.

* Error handling is so far missing. Each step should be able to provide an 
error handler, and by default errors should bubble up, so you only have to 
handle errors at the end (probably as an error handler continuation of the 
future).

* We probably should have a way to abort a job (if the job supports that of 
course).

* Execution is so far tied to the event-loop, and I'm wondering whether we 
should also support non-eventloop execution, i.e. to be executed in a thread.
Can we specialized the executors for that?

Otherwise it looks really nice =) Let me know what you think about the points 
above and whether you plan on working on them, otherwise I might give it a try 
as well ;-)

Cheers,
Christian
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/