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? 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...
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? > > 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. Agreed. Sounds reasonable :) > 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. 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 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...
Am Sa 29 Sep 2007 07:06:14 CEST schrieb Dan Williams <[EMAIL PROTECTED]>: > On Fri, 2007-09-28 at 08:21 +0200, Helmut Schaa wrote: >> Hi, >> >> Am Freitag, 14. September 2007 22:22:33 schrieb Dan Williams: >> > 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(). >> >> Works for me/KNM now :) > > Tambet has a patch to change the activation call a bit. Basically, the > code sucks in NM right now to handle the deferred activation, so we'd > like to move the Device.Activate() method to the NMManager object, where > you would call NMManager.ActivateDevice() instead. The Deactivate() > call would still be on the Device object. Sound OK? It makes the > internal NM code for deferred activation a lot cleaner. ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Not sure about this. The interface would be much more obvious if Activate would stay as a device-method. >> Yippee, yesterday I was able to create a new wired connection on the fly and >> directly activate it. > > Awesome :) > >> Static IP configuration does not work yet (even if I send an IPv4 setting), >> right? > > Not yet, but it's likely easy to do. 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 Fri, 2007-09-28 at 08:21 +0200, Helmut Schaa wrote: > Hi, > > Am Freitag, 14. September 2007 22:22:33 schrieb Dan Williams: > > 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(). > > Works for me/KNM now :) Tambet has a patch to change the activation call a bit. Basically, the code sucks in NM right now to handle the deferred activation, so we'd like to move the Device.Activate() method to the NMManager object, where you would call NMManager.ActivateDevice() instead. The Deactivate() call would still be on the Device object. Sound OK? It makes the internal NM code for deferred activation a lot cleaner. > Yippee, yesterday I was able to create a new wired connection on the fly and > directly activate it. Awesome :) > Static IP configuration does not work yet (even if I send an IPv4 setting), > right? Not yet, but it's likely easy to do. Dan ___ 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 Freitag, 14. September 2007 22:22:33 schrieb Dan Williams: > 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(). Works for me/KNM now :) Yippee, yesterday I was able to create a new wired connection on the fly and directly activate it. Static IP configuration does not work yet (even if I send an IPv4 setting), right? Thanks, 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...
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...
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(). Thanks, Dan > > 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
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
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
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
