D19677: WIP: Port UDisks to using DBus ObjectManager

[Stefan Brüns]

bruns added a comment.


  In the old code, the backend was created lazily, as the associated DBus connection was expensive, this is no longer the case. I am wondering if creating the backend immediately/always would not solve a number of structural problems here (though this is already *much* better than what we have curently). We could store the properties in the backend (non-flattened), and return the flattened map on demand. For normal property lookups, we would just walk the interfaces and lookup the key/value.

INLINE COMMENTS

> udisksdevicebackend.cpp:111
>  {
> -    QDBusMessage call = QDBusMessage::createMethodCall(UD2_DBUS_SERVICE, m_udi, DBUS_INTERFACE_PROPS, "GetAll");
> -
> -    Q_FOREACH (const QString &iface, m_interfaces) {
> -        call.setArguments(QVariantList() << iface);
> -        QDBusPendingReply<QVariantMap> reply = QDBusConnection::systemBus().call(call);
> -
> -        if (reply.isValid()) {
> -            auto props = reply.value();
> -            // Can not use QMap<>::unite(), as it allows multiple values per key
> -            for (auto it = props.cbegin(); it != props.cend(); ++it) {
> -                m_propertyCache.insert(it.key(), it.value());
> -            }
> -        } else {
> -            qCWarning(UDISKS2) << "Error getting props:" << reply.error().name() << reply.error().message();
> +    m_propertyCache.clear();
> +

Why is this always cleared? I think a `if (!m_propertyCache.isEmpty) { return; }` would be correct here.

REPOSITORY
  R245 Solid

REVISION DETAIL
  https://phabricator.kde.org/D19677

To: broulik, #frameworks, bruns
Cc: apol, nicolasfella, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190523/6e6f84dd/attachment.html>