[Kde-hardware-devel] Getting rid of synchronous and uncached accessors in Solid

[Kevin Ottens]

On Friday 4 June 2010 01:27:39 Dario Freddi wrote:
> This is mostly for Solid::Control, but caching properties in Solid would be
> great as well.

Well, that's what "QMap<QString, QVariant> cache" in HalDevicePrivate is for. 
;-)
 
> Thoughts, opinions? (Kevin I'm mostly looking at you)

I clearly agree with all the above regarding stress and delays on the bus.

That said, it's not like there's any of the Solid::Control calls which are on 
some hot path AFAIK. They are for most cases called not fairly often.

I guess you sent this mail after some Telepathy-KDE/Collabora "brainwashing". 
In the case of Telepathy it makes perfect sense to be very aggressive on the 
way caching is done, and having most of the wrapper API written in an async 
fashion. The usage pattern of such an IM infrastructure is much more stressful 
on the bus and clients can't afford blocking for 100ms. In the case of 
Solid::Control I'm very doubtful about the perceived performance benefit for 
the user on maintenance cost ratio (especially since what really uses to 
Solid::Control are policy daemons just reacting to some state changes, UIs 
being insulated in other processes just accessing simpler interfaces after all 
the data got crunched).

Also, I have to wonder if that'd be well invested time to do that on 
Solid::Control at that point when the plan is to make it slowly disappear. Why 
not just do this kind of cleanup for after you rolled it back into PowerDevil 
as we planned? This way you won't be tied to the Solid::Control interfaces 
anymore, I think you'd waste less time in the long run by delaying such a 
cleanup.

Let's focus on the "kill Solid::Control plan" instead, shall we?

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100604/c2414251/attachment.sig