Turing the NM UI into an agent
- From: Marcel Holtmann <marcel holtmann org>
- To: networkmanager-list gnome org
- Subject: Turing the NM UI into an agent
- Date: Wed, 26 Mar 2008 18:35:50 +0100
since you are re-working most of the D-Bus APIs based around Network
Manager, I like to propose a radical change on how you handle the UI
part. Personally I think that the current UI inside Network Manager
(even with 0.7) has too much tasks to fulfill. I prefer having a
So my main concern is that replacing the current UI is too
complicated. One reason is that you need a well known bus name for the
UI on the system bus. This makes it impossible to install two UI
components or split tasks between two applications. We did the same in
the early days of BlueZ and I think it is not a good design to hard-
code a well known bus name into the daemon and have the UI use the
same one. So for BlueZ we came up with the D-Bus agent concept. So let
me try to explain it.
So the UI only gets a unique name (no need for a D-Bus security file).
Then it registers itself a object path (the actual path value is
unimportant). After that it calls a RegisterAgent(object path) method
inside the daemon. Now the daemon knows where to find an agent (object
path and the unique name from the message sender value) and can call
into this object for additional information. It really serves as a
callback interface and the only things to agree on is the interface
description. The bus name and object path are kept random.
This concept allows an easy way of monitoring agents. So you know the
case when you have no agent (meaning no UI is running) or when an
agent dies. No unneeded D-Bus calls that might fails etc. The other
advantage is that in theory you can stack agents and call them in
order. This is useful if you have a wizard or some small cases where
the UI should look different from the general case. Or unregister and
then re-register agents. For example for multi user scenarios.
] [Thread Prev