On Tue, 25 Aug 2015 17:06:52 +0100
Edward Bartolo <edbarx@???> wrote:

> Rethinking about it, there is no need to use the ESSID in the table.
> A table like the following would do the job neatly, in my humble
> opinion. ESSIDs are already saved in the interfaces files, so a table
> like the following is enough:
> 00001 "my little wifi at home"
> 00002 "my wifi at work"
> 00003 "wifi at cafe"
>
> Users only need to remember the name of connections, not what iwlist
> found: ESSIDS and passwords are already saved. Using descriptions is
> more user oriented rather than using ESSIDs.
>
> So, the GUI would read this file. Display the pseudo names (user
> descriptions) and select the interfaces files using the table. For
> instance, if user clicked "my wifi at work", that would mean, file
> 00002 which obviously already contains an ESSID and password. What we
> cannot avoid is, that ESSID names, must be of the required standard. I
> can implement this, but I need the opinion of others.

Hi Edward,

First of all, as far as I can tell, the storage of essids with their
passwords is only the back end's business. The front end gets its list
of essid candidates directly or indirectly from iwlist $device
scanning, and tells the back end what it wants to do and the essid it
wants to do it with.

As far as the back end, if it becomes a problem to name an interface
file after its essid, as long as the essid is reliably greppable, it's
trivial to make a command to, in real time, translate essid to
interface filename. I imagine most people will have less than 100
essids on record. Grepping 100 interface files takes much less than a
second, so there's no performance reason to build an index table. That
would improvement with 10,000 or 100,000 essids, but not 100.

I think it would help the discussion if you gave us a few examples of
these interface files, including at least one for a permanently wired
connection.

Anyway, the whole point is to keep it simple, so for this application
I'd say tables are overkill: Just grep at runtime: in the human
perception of time, it's just as fast.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust