KActivities library optimizations

[Aaron J. Seigo]

On Tuesday, September 4, 2012 11:28:22 Ivan Čukić wrote:
> I don't like the idea of having a simple requests like activity list
> or info with async api. This would be quite imitating for simple
> clients like loopless kio_activities, or file item plugin. It would be
> nicer to have something like std::async(...some method...).

for the simple requests API, one possibility is to have a class that you 
instatiate and which pre-propulates (as the current class does) and signals 
when it is ready for use. turning this sync is really easy (for things like 
kio_activities), using the pattern seen in many other classes with exec() or 
waitForFinished() methods (which can be paired with value classes that use 
this explicitly as seen in QtDBus).

iow, the API can be async with a "make this sync, please" convenience method 
for cases where it truly is ok to be sync.

one thing i'm not a fan of with the new Consumer approach is that it is 
impossible to know whether the code will block or not. it does a pre-fetch and 
then cleverly blocks only if it hasn't received a reply yet. which means there 
is no way to guarantee async behaviour when desired. as long as the calls to 
kactivitymanagerd are blazingly fast (and/or Consumer is always created in 
sufficiently in advance of usage) this is a minor issue.

> For the slower methods (linked resources, and similar), I'd go for it,

yes, these probably really need to be async ...

> or remove it since we IIRC don't use it in any important place.

but we want to, right?

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120904/251175a0/attachment.sig>