- Introduce the user to per SSID/Security Wifi networks grouping - Agent is no longer a future feature and user should be aware of how he can provide required information when connecting to a service. --- doc/overview-api.txt | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/doc/overview-api.txt b/doc/overview-api.txt index 14fec14..fc265f5 100644 --- a/doc/overview-api.txt +++ b/doc/overview-api.txt @@ -197,7 +197,7 @@ included in this list. They will only show up once a carrier is detected. The service interface is not meant for basic device configuration task. So switching a device on and off (via RFKILL for example) should be done via -the device interface. +the technology interface. Due to limited screen size of small devices and the big amount of WiFi access points that are deployed right now it might be sensible to not show @@ -219,6 +219,19 @@ In case of WiFi this will be the SSID value. The SSID is a binary array and will be converted into printable form. Unprintable characters are replaced with spaces. +In addition to WiFi naming, WiFi networks are subject to a specific grouping +policy performed around SSID and security type. Which means, for n wifi +networks providing the same SSID and the same security: this will be seen +under one and only one service. For instance, if 5 AP servicing SSID TEST +with WPA2 authentication method and 2 AP servicing the same SSID with open +authentication method are present, the user will see only 2 services listed +with the same name TEST differentiated by their security type: psk and none. +Such policy is also applied to hidden networks, where hidden service will +have an empty name and will be differentiated by the security type. User has +then to connect to the right one, from security point of view. The agent +will be requested for any required information (See "Application basics" +below). + For Bluetooth the device alias is used. The alias is different since it can be overwritten by the user via the Bluetooth service. The identification is still done based on its address, but the display name might change. In @@ -376,9 +389,14 @@ will result in an error if no cable is plugged in. All connection attempts can fail for one reason or another. Application should be able to handle such errors and will also be notified of changes via signals. -In future versions Connection Manager will interact with an agent to confirm -certain transactions with the user. This functionality is currently not -implemented. +Connection Manager will interact with an agent to confirm certain transactions +with the user. If ConnMan needs extra information, ConnMan will ask the user +for exactly the information it requires: passphrase, network's name (for hidden +ones) and more depending on the use case (WPS, EAP, ...). +So all the request from the agent are 1:1 question that a user should answer. +Therefore, all application dealing with ConnMan might implement an agent +following the right API (see agent-api.txt) to interactively answer to +ConnMan's requests. To monitor the current status of a service the state property can be used. It gives detailed information about the current progress. -- 1.8.1.2 _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
