Re: [Interest] QtDBus interface design question
On quinta-feira, 7 de novembro de 2013 19:01:57, Roland Winklmeier wrote:
Hey there,
Hello Roland
As promised, I have found time to read your email and reply.
I have a daemon application built with C++/Qt. It is a client for a
network and should run in the background. The plan was to connect the UI
via DBus to this daemon in order to make the objects inside the daemon
also available to other external tools/addons. So far nothing special,
this is done in many places in KDE.
When discussing D-Bus, please don't mention network :-)
People might jump at you and say that D-Bus isn't meant to be used across a
network. That's not what you're trying to do -- your application just happens
to do networking somewhere else in it.
The thing is , the object hierarchy is quite deep and complicated. The
best example is the object managing the applications settings, lets call
it CSettingsManager : public QObject. It holds several client QObjects,
representing each a different setting group:
CSettingsManager
|--- CServerSettings
|--- CUserSettings
|--- CLoggingSettings
|--- CGuiSettings
Now we want to expose these hierarchy via DBus. After reading thousands
of DBus applications and their interfaces, we decided to try the
following interface:
/CSettingsManager
/CSettingsManager/CServerSettings
/CSettingsManager/CUserSettings
/CSettingsManager/CLoggingSettings
/CSettingsManager/CGuiSettings
Sounds reasonable.
I think up to now its convenient. Instead of passing custom classes via
DBus, I thought its better to register the child objects too and just
point to the object via a QDbusObjectPath argument. So anyone can act
and react on the real object via DBus.
For example I can call CSettingsManager::getServerSettings() {return
QDBusObjectPath /CSettingsManager/CServerSettings } and create a
QDbusAbstractInterface with the returned objectpath and call methods on
the child object. So far so good. I have to mention here, the number of
CServerSettings is dynamic and decided during runtime (based on what is
specificed in the configuration file).
I'm not sure I understood what you meant here.
If the path is fixed and known to all clients, there's no point in adding a
method that returns it. If it's always going to be the same, the clients
should just avoid the extra round-trip and should send the request directly.
Maybe what you meant is because of what follows:
The DBus interface for example could look like:
/CSettingsManager/CServerSettings/Server1
/CSettingsManager/CServerSettings/Server2
...
/CSettingsManager/CServerSettings/ServerN
Sounds good. Your first idea has probably been to register one QObject per
path. That's a valid solution. However, do it only if you had those QObjects
(one per path) anyway, to hold the data and to control the lifetime.
Otherwise, there's another trick: you can register the same QObject multiple
times and simply get the targeted path from the incoming QDBusMessage (which
you can get by deriving that class multiply from QObject and from
QDBusContext).
The issue is now, I want to have a table view displaying the properties
for each Server and let the user edit it.
--
|Server 1 | IP address | port | name |
|Server 2 | IP address | port | name |
|Server 3 | IP address | port | name |
--
Why do you want to have that table? Is that normal activity in your service?
Or is this something that you'll use once in a blue moon, to test how it's
going?
The reason I ask is that the answer will determine whether you should have a
fast API to retrieve everything, or if it's acceptable that the client must do
multiple calls to collect all the information.
I could get a list of all objects and start retrieving their properties,
but lets suppose I have 1000 rows with 4 properties each = 4000 Dbus
calls to build the table. The performance would be horrible.
Indeed, hence the question above.
The only solution I can imagine is to pass the entire table in one DBus
message, but how. I cannot pass the objects itself, because I cannot
transfer an QObject via DBus. Creating plain structs and pass them is an
option but is rather dirty to me.
Creating structs and passing an array of structs is the only way.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtDBus interface design question
Hi mandeep, thanks for the answer. I was a little bit concerned, since I also want to have the possibility to sort the table, but with transfering only strings, I would loose the operator () implementation. But I think I can workaround that, by passing an enum with the sort order and let the sender to the sorting already. I'm going to do some benchmarks, how fast each of the solutions are and choose the quickest. Maybe some DBus interface design expert can suggest something else meanwhile. BR, Roland Am 08.11.2013 08:53, schrieb Mandeep Sandhu: The only solution I can imagine is to pass the entire table in one DBus message, but how. I cannot pass the objects itself, because I cannot How about returning an array of strings in the method call? Both are valid DBus types and you could probably concatenate the various properties using a delimiter and tokenize them at the receiver end. I'm no dbus expert and have mostly used QtDbus to communicate with existing services, like NetworkManager etc, so CMIIW! :) HTH, -mandeep transfer an QObject via DBus. Creating plain structs and pass them is an option but is rather dirty to me. How are DBus experts handling this? I know our DBus interface is quite complex and most others are far easier, but there must be a solution. I'm still a DBus noob, so any hint how to change the design would be very very welcome. Thanks very much Roland ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QtDBus interface design question
Hey there,
I'm struggling with a design issue and cannot find a easy and clean
solution. So I hope you experts could help me out maybe.
I have a daemon application built with C++/Qt. It is a client for a
network and should run in the background. The plan was to connect the UI
via DBus to this daemon in order to make the objects inside the daemon
also available to other external tools/addons. So far nothing special,
this is done in many places in KDE.
The thing is , the object hierarchy is quite deep and complicated. The
best example is the object managing the applications settings, lets call
it CSettingsManager : public QObject. It holds several client QObjects,
representing each a different setting group:
CSettingsManager
|--- CServerSettings
|--- CUserSettings
|--- CLoggingSettings
|--- CGuiSettings
Now we want to expose these hierarchy via DBus. After reading thousands
of DBus applications and their interfaces, we decided to try the
following interface:
/CSettingsManager
/CSettingsManager/CServerSettings
/CSettingsManager/CUserSettings
/CSettingsManager/CLoggingSettings
/CSettingsManager/CGuiSettings
I think up to now its convenient. Instead of passing custom classes via
DBus, I thought its better to register the child objects too and just
point to the object via a QDbusObjectPath argument. So anyone can act
and react on the real object via DBus.
For example I can call CSettingsManager::getServerSettings() {return
QDBusObjectPath /CSettingsManager/CServerSettings } and create a
QDbusAbstractInterface with the returned objectpath and call methods on
the child object. So far so good. I have to mention here, the number of
CServerSettings is dynamic and decided during runtime (based on what is
specificed in the configuration file).
The DBus interface for example could look like:
/CSettingsManager/CServerSettings/Server1
/CSettingsManager/CServerSettings/Server2
...
/CSettingsManager/CServerSettings/ServerN
The issue is now, I want to have a table view displaying the properties
for each Server and let the user edit it.
--
|Server 1 | IP address | port | name |
|Server 2 | IP address | port | name |
|Server 3 | IP address | port | name |
--
I could get a list of all objects and start retrieving their properties,
but lets suppose I have 1000 rows with 4 properties each = 4000 Dbus
calls to build the table. The performance would be horrible.
The only solution I can imagine is to pass the entire table in one DBus
message, but how. I cannot pass the objects itself, because I cannot
transfer an QObject via DBus. Creating plain structs and pass them is an
option but is rather dirty to me.
How are DBus experts handling this? I know our DBus interface is quite
complex and most others are far easier, but there must be a solution.
I'm still a DBus noob, so any hint how to change the design would be
very very welcome.
Thanks very much
Roland
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtDBus interface design question
The only solution I can imagine is to pass the entire table in one DBus message, but how. I cannot pass the objects itself, because I cannot How about returning an array of strings in the method call? Both are valid DBus types and you could probably concatenate the various properties using a delimiter and tokenize them at the receiver end. I'm no dbus expert and have mostly used QtDbus to communicate with existing services, like NetworkManager etc, so CMIIW! :) HTH, -mandeep transfer an QObject via DBus. Creating plain structs and pass them is an option but is rather dirty to me. How are DBus experts handling this? I know our DBus interface is quite complex and most others are far easier, but there must be a solution. I'm still a DBus noob, so any hint how to change the design would be very very welcome. Thanks very much Roland ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
