Re: Turing the NM UI into an agent

Hi Dan,

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
"stupid" UI.

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.

There's already a split between the UI bits and the configuration bits; I think what you'd like to see is the User Settings service grab unique bus names so that each user could provide their own user settings at the
same time to NetworkManager.  I'd like to go there in the future, but
then we need to figure out things that ConsoleKit will help with, but
which are still very much undefined, stuff like:

- If user A has activated a connection on eth0, is user B allowed to
control eth0 and potentially tear down user A's connection?

- If user A has activated eth0, is user B allowed to start a VPN
connection on eth0?

Stuff like that.  There might be uses for this sort of thing in
virtualization actually, but it's kind of hard to see networking as the
same sort of thing as Multi-User X, for example, where different users
get exclusive access to individual mice, keyboards, displays, and USB
flash drives.

I wasn't talking on these kind of things. They are totally different.

Right now the only thing that acquires a well-known bus name is the
settings service, which doesn't have to have an UI at all. Up until NM 0.5 it actually was a completely separate process from the applet. If your user has permissions to do so at the D-Bus level (ie, at_console or
whatever), then any process can call
ActivateConnection/DeactivateConnection right now.  But only 1 process
can provide the configuration data, which limits the set of what
ActivateConnection can actually connect to.

I meant the settings service. Still need to get deeper into the Network Manager terminology. So having a "static" settings service is a bad design (from my perspective). Turning the settings service into agent would be a good thing. From the logical point of view it is not really different, but from a technical point of view it makes all the difference.

So I see the UI as something totally "stupid" that the daemon tells it what to do and the user can use it to influence settings inside the daemon. Besides that both are loosely coupled.

An example would be that the daemon needs a passphrase for a network. So it calls a callback inside the UI agent. This call should always go to the logged in user and thus to the applet run by that user. Any other callback into the UI (or settings service) should be like this.

So big technical advantage here is that the daemon always knows if an agent is present or not. And if not, it can do a proper fallback. Calling a D-Bus method that fails is a bad thing. Also the fact that you don't have to agree on a well known name and object path makes this a lot cleaner. The D-Bus interface for the agent should be the only contract between the UI and the daemon. The rest a variable details.

Could you describe some of the scenarios that would involve stacking UI
agents?  I'm not sure I follow the use-cases here.

So you have the applet handling all security request (passphrase etc.), but then you wanna do a wizard to setup a new network connection. In that case you could re-direct the passphrase request to the wizard (which is a different application from the applet). While for WiFi this might be still limited in its usefulness. For all the other wireless technologies like Bluetooth, WiMAX, UWB etc. it is different.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]