KActivities library optimizations

[Ivan Čukić]

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

Without the blocking. the hell would break loose - it wouldn't be backwards 
compatible and every kactivities client would need to be patched.

> > or remove it since we IIRC don't use it in any important place.
> but we want to, right?

Not really. The method that only gets a list and doesn't notify you on changes 
and similar is not that useful in my opinion.

We need data models for it (currently, this specific case is covered by 
Nepomuk::Query that is used in PA)

Ch!

-- 
You know, there are many people in the country today who,
through no fault of their own, are sane. Some of them were born sane.
Some of them became sane later in their lives...
  -- Monty Python's Flying Circus
-------------- 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/b11af468/attachment.sig>