4.5 - Activities

[Aaron J. Seigo]

On March 10, 2010, Ivan Čukić wrote:
> > hmm. am i reading this correctly that this kded service is only needed if
> > nepomuk is not there, and that it serves as a cache-in-the-middle between
> > nepomuk and the applications? this seems like a lot of overhead just to
> 
> this was one of the kwin people wishes. Even with nepomuk, a cache-in-the
> middle is benefitial here since we don't really need the overhead of
> querying nepomuk when a user switches the activity.

that sounds like premature optimization to me. we can always add a client-side 
cache easily inside the classes themselves if this turns out to be "too slow" 
(to whatever our definition of that is :). don't forget  there's also a 
penalty for keeping the cache in sync across multiple clients.

the other concern is memory usage due to having that cache around ... 

i'd really suggest keeping in mind how a cache can be implemented, ensure the 
API doesn't prevent that, and then implement the "naive" approach first and 
measure it from there.

> > there there is the topic of signals ... dbus signals suck majorly. they
> > are broadcast to every application on the bus whether they care or not.
> > might it be better if ActivityConsumer registered itself over dbus with
> > the kded service which would then call async methods on these registered
> > objects as needed? this is what we're doing with jobs, notifications and
> > the system tray.
> 
> Ok. We could do that - I had no idea dbus signals were that badly designed.

yes, it's really disappointing :(

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks