I've been thinking a little more about the libnwam API
requirements for information about WiFi networks
visited - currently stored in the /etc/nwam/known_wifi_nets
file. It seems to me that as well as storing ESSID, we need
to have a format which supports addition of BSSID information
in the future (since at present BSSID info is ignored in connect
requests), and supports a prioritization of the visited wifi
networks (see p13 of the NWAM GUI spec - "Connection
Properties : Wireless") via "up" and "down" buttons.
With these facts in mind, I suggest we go with a similar
object model to that used for NCUs, ENMs and locations
whereby a given object (a WLAN in this case) has a
set of associated properties. In the case of a WLAN,
at present we'll store a list of visited BSSIDs (which
may be used in the future) and a priority. It make
make sense to record other information too such
as the security mode (WEP, WPA or none) for a
hidden WLAN (I don't think this is available on scan,
but if the user specifies it once it could be stored).
So the basic API functions would be:
nwam_error_t nwam_known_ap_create(const char *essid,
nwam_known_ap_handle_t *aphp);
nwam_error_t nwam_known_ap_read(const char *essid,
nwam_known_ap_handle_t *aphp);
nwam_error_t nwam_known_ap_commit(nwam_known_ap_handle_t aph);
nwam_error_t nwam_known_ap_destroy(nwam_known_ap_handle_t aph);
nwam_error_t nwam_walk_known_aps(int(*cb)(nwam_known_ap_handle_t, void *),
void *data, uint64_t flags, int *retp);
nwam_error_t nwam_known_ap_set_prop_value(nwam_known_ap_handle_t aph,
const char *prop, nwam_value_t value);
nwam_error_t nwam_known_ap_get_prop_value(nwam_known_ap_handle_t aph,
const char *prop, nwam_value_t *valuep);
We could build simpler functions on top of these along the
lines of what Jim had for phase 0.5, but I think it might
make sense to go this way to allow association of multiple
properties (such as visited BSSID list, priority, etc) with a
visited WLAN name. What do people think?
Alan
