On Fri, 2010-03-19 at 22:02 +0100, van Schelve wrote: > Hi. > > I know about several discussions about pre-up and pre-down in the past. > Dan, I understand your position and I can follow your arguments against.
Yes, I realize there are use-cases where such operations would be nice to have, and I'm open to it. I haven't gotten around to reviewing the patch yet though, and it's a fairly major change to the flow of things so it's not something to be undertaken lightly. > But I see a number of usecases where I dont have any idea instead of doing > it with pre-up / pre-down scripts in nm-dispatcher. I know every script in > these phases is a potential risk for nm functionality. From nm site you > have no chance to control those scripts and it might be that users will > come up with problem reports that are based on their own scripts. > > For example. We need to find solutions for these problems: > 1. unmount cifs shares before a connection becomes disconnected Right, but remember that this is only possible *sometimes*. There will always be times where the connection just died and no clean disconnection is possible. But in cases where it's possible to do so, we should probably try to give these operations at least a few seconds to complete before killing the connection. > 2. stop any other active connection when a user select another one (maybe > this can also be done in down event) to make sure the system is single > homed I don't really see the value of this actually. In practice, the multi-homing is not an issue and it should be transparent. Multi-homing is also required for less interruption in network connections. If you had to wait 30 seconds to connect to a wifi access point after unplugging a cable every time, that's annoying. I'll also note that Windows and Mac OS X have been multi-homed by default for years. > 3. disconnect from the active vpn before the underlaying connection > becomes disconnected Yes. > 4. start replication of the mail client before really disconnecting Yes, though this has the potential to take a really long time. How long do we give something like this? I'm not sure I see a usable way to do this sort of thing if you have say some megabytes of mail to pull over a slow connection, for example. It might work some places, but certainly not many other places like 3G connections. This one needs more thought about what the workflow would be like. How does the user indicate their desire to disconnect? How do we know how long they are willing to wait before they really do want to take their laptop with them? etc. > Maybe I'm off the track looking fixed to pre-up / pre-down as solution for > these problems. If so please point me onto the right way. Most of these are pre-down really; the major use-cases I've seen for pre-up have been stuff like captive portal login scripts. I went through all the pre-up and pre-down scripts in an Ubuntu install last year, and 80% of them were completely bogus things like munging the wifi attributes, or working around out-of-kernel wifi driver bugs, or other stuff that no longer needs to be done. But there are some valid cases like you suggest. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
