Re: HEAD 1.450 applet.c patch

[Bill Moss <bmoss CLEMSON EDU>]

What I really objected to in the current behaviour was the 'forced 
writing of the ESSID' to GConf by the nmwa_date_network_timestamp 
function if the ESSID does not exist. I have no problem with updating 
the timestamp on an existing network that has a defined ESSID but why 
use the nmwa_date_network_timestamp function to write a new ESSID to 
GConf? So I would be happy if the nmwa_date_network_timestamp were 
modified so that it does what its name says; i.e. it updates the 
timestamp but it does force write new ESSIDs to GConf.

Bill

Dan Williams wrote:

> On Mon, 2005-08-15 at 10:47 -0400, Bill Moss wrote:
>  
>
> > The 'Connect to Other Network...' dialog will add a menu item to 
> > 'Wireless Networks' and will add the entered ESSID and a timestamp to 
> > GConf. If the user makes an error in typing the ESSID or is just 
> > experimenting, he end up with multiple bogus entries in GConf. Following 
> > the theme of not adding data to GConf until it has been verified by a 
> > successful connection, I submit the attached patch to gnome/applet/applet.c.
> >
> > The call to nmwa_date_network_timestamp in nmwa_menu_item_active has 
> > been removed. Since this is the only place the function 
> > nmwa_date_network_timestamp is used, it has been eliminated as well.
> >    
>
> Hmmm.  Ok, the reason this was initially in the place it was, was to
> make sure that network timestamping was done only by the user, and not
> by whatever NetworkManager decided the network of the week was.  i.e.,
> imagine this situation:
>
> 1. User selects network 'preferred', it now has the highest timestamp
> and is the network the user really wants
> 2. User shuts down, goes away
> 3. User comes back, starts up.  'preferred' isn't noticed in the first
> couple scans (which is just the way wireless works), so NetworkManager
> connects to the 'less-preferred' network instead.  Highest timestamp is
> on 'less-preferred', which is wrong since the user did not explicitly
> select 'less-preferred' to connect to.
> 4. Next time user starts up, it will default to 'less-preferred'
>
> I'm curious how we fix that in this scenario.  In NetworkManager, we
> know if the user explicitly requested connection to the access point, or
> whether NM just decided to use the next-best-one.  So we could add a
> boolean to the update-network-info dbus call that would indicate as
> such, and the applet/info-daemon could do whatever it wanted to, right?
> That sounds plausible to me and preserves the current behavior.
>
> Dan
>
>
>  

--
Bill Moss
Professor, Mathematical Sciences
Clemson University