Re: Note about device activation in current trunk...
On 9/29/07, Helmut Schaa [EMAIL PROTECTED] wrote: ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Internally, yes, but it will not be exposed over dbus. Not sure about this. The interface would be much more obvious if Activate would stay as a device-method. Not really. Devices don't have any stored connections you reference by path and service_name argument, NMManager has. It would make just as much sense as NMConnection.Activate(o device_path) than the other way around. Since the manager keeps track of devices and connections and thus ties them together, it's the obvious place for the activation. The reason why it was NMDevice.Activate(connection) was that it used to make sense when the whole connection was sent to the device with activation request. The problem was, that would not work with system connections (pre-configured by system administrator) where only the connection path is available for the user activating the connection. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
On 10/1/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Montag, 1. Oktober 2007 08:02:18 schrieb Tambet Ingo: On 9/29/07, Helmut Schaa [EMAIL PROTECTED] wrote: ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Internally, yes, but it will not be exposed over dbus. So, how would the call look like? node name=/ interface name=org.freedesktop.NetworkManager method name=ActivateDevice annotation name=org.freedesktop.DBus.GLib.Async value=/ arg name=device type=o direction=in/ arg name=service_name type=s direction=in/ arg name=connection type=o direction=in/ arg name=specific_object type=o direction=in/ /method /node Note that the call is supposed to be asynchronous: It will not return before it knows the device activation will be started. If the connection referenced by connection object path is not found, NM waits for up to 5 seconds in hope to receive the connection. If the call is made synchronously (from a single threaded app, that is), there is no way NM would be able to update it's known connections from the frontend (which is blocking on waiting for the reply). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
Hi, Am Fr 14 Sep 2007 22:22:33 CEST schrieb Dan Williams [EMAIL PROTECTED]: On Fri, 2007-09-14 at 11:49 +0200, Helmut Schaa wrote: Am Donnerstag, 13. September 2007 19:15:13 schrieb Dan Williams: Yeah, I know this is a problem at the moment, because it's unlikely NM has gotten the configuration info for the connection yet. This is what I'm fixing today; I believe the issue needs to be solved in NM itself to keep the APIs and interface behavior simple for clients like knm and nm-applet. Agreed ;) Committed to svn. Can you test out and report? Make sure knm emits the NewConnection signal on it's settings service when it adds the connection it's just created before calling device.Activate(). I'm on vacation next week. I'll try it as soon as possible and report back later :) Regards, Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
Am Donnerstag, 13. September 2007 19:15:13 schrieb Dan Williams: Yeah, I know this is a problem at the moment, because it's unlikely NM has gotten the configuration info for the connection yet. This is what I'm fixing today; I believe the issue needs to be solved in NM itself to keep the APIs and interface behavior simple for clients like knm and nm-applet. Agreed ;) NM internally will always request the connection details when a new connection appears from the user settings daemon, so it's a matter of teaching the activation code to wait a bit before failing the activation, probably with a timer. The Activate() interface was done with object paths because NM has to have the connection object path when it calls GetSecrets(), and its simpler in the client to have this all be in the same place rather than special casing new NMConnections that NM may/may not know about yet. Assume that NM will do the right thing here and activate a connection you tell it about, that it may not yet have. Thanks, Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Note about device activation in current trunk...
Hi, I just tried to implement the feature create new connection in KNM and ran into the following problem: After entering all information for the new connection KNM sends the NewConnection-signal to NM and afterwards calls the Activation-method for the appropriate device. Unfortunately NM did not get the settings (which are requested during NewConnection-signal-processing) for this connection yet when the Activation-call arrives and therefore fails :( I'm not sure but most likely nm-applet will have the same problem (this feature is not implemented in nm-applet yet). Dan, Tambet, how can we avoid this issue? Regards, Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
On Thu, 2007-09-13 at 16:44 +0200, Helmut Schaa wrote: Hi, I just tried to implement the feature create new connection in KNM and ran into the following problem: After entering all information for the new connection KNM sends the NewConnection-signal to NM and afterwards calls the Activation-method for the appropriate device. Unfortunately NM did not get the settings (which are requested during NewConnection-signal-processing) for this connection yet when the Activation-call arrives and therefore fails :( Yup. I'm not sure but most likely nm-applet will have the same problem (this feature is not implemented in nm-applet yet). I did this last night actually. Dan, Tambet, how can we avoid this issue? Yeah, I know this is a problem at the moment, because it's unlikely NM has gotten the configuration info for the connection yet. This is what I'm fixing today; I believe the issue needs to be solved in NM itself to keep the APIs and interface behavior simple for clients like knm and nm-applet. NM internally will always request the connection details when a new connection appears from the user settings daemon, so it's a matter of teaching the activation code to wait a bit before failing the activation, probably with a timer. The Activate() interface was done with object paths because NM has to have the connection object path when it calls GetSecrets(), and its simpler in the client to have this all be in the same place rather than special casing new NMConnections that NM may/may not know about yet. Assume that NM will do the right thing here and activate a connection you tell it about, that it may not yet have. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
