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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel