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.


Edward


On 25/08/2015, Irrwahn <irrwahn@???> wrote:
> On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote:
>>
>>
>> Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo
>> <edbarx@???>:
>>> We can easily avoid having to encode ESSIDs by creating a file
>>> containing a texual lookup table as the following, but since the
>>> project is already functional, it looks like rebuilding a house that
>>> is already habitable.
>>>

>>> essid1    "my little wifi at home"
>>> essid2    "oops, wifi at my partner's!"
>>> essid3    "wifi at work, without my boss' knowing"
>>> essid4    "wifi at library"

>>>
>>> Ok, you get it. No need of encoding anything and the user can describe
>>> his wifi with whatever he deems justified.
>>>
>>> Edward
>>
>> IMHO:
>>
>> If we use a mapfile, we have the encoding problem *there* instead of the
>> wifi directory filenames ... It will only move the problem, not solve it
>> :D
>>
>> i wonder if we ever get to see such SSIDs from iwlist anyway - how is it
>> supposed to print SSIDs that contain the zerobyte ...
>
> If we can drop the requirement to cope with '\0's, as the frontend
> uses iwlist and grep(!) to acquire the SSID, this would leave us with
> just the '/' to encode. The most "evil" thing we'd had to expect
> would be "////////////////////////////////".
>
> Thinking about it, one can even do away with all the allocation stuff
> and just use a single fixed size buffer of 32 * 3 + 1 bytes to hold
> the filesystem friendly encoded version, since there are no thread
> safety contraints imposed on the backend.
>
> --
> Irrwahn
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>