This is the second step for WISPr. We need to have WebAPIs to insert, delete, and change SSID for WISPr SSID list. These interfaces will be used in FTU and setting app.

We actually already have these APIs: Add: Bug 923443 adds the capability of adding network but not associating with it. Delete: MozWifiManager.forget Change: Delete then Add The only limitation is all of these APIs only works when wifi is enabled. If we need these operations functional even if wifi is disabled, the simplest solution is to create a file to save these pending operations and execute them whenever wifi is enabled. This approach can be also implemented in the application level to keep internal wifi machinery as simple as possible.

For this proposal, only one additional web API is required, which is navigator.mozRegisterWisprNotification(DOMString ssid) Gaia needs only two APIs, system message 'wispr-login' permission and 'wifi-manage' permission to acquire the capability to implement full WISPr function: 1) navigator.mozRegisterWisprNotification('MY_WISPr_SSID'); 2) navigator.mozSetMessageHandler('wispr-login', function handleLogin() {...}) Some functions need to add to gecko: 1) A database to save the registered records of <ssid, manifest_url, page_url>. <ssid, manifest_url> may be the primary key. 2) The implementation of |navigator.mozRegisterWisprNotification| adds the entry to WISPr database. 3) While captive portal is detected, gecko determines if the response from the PAC gateway is WISPr. It it is NOT WISPr, go for original captive portal path. If it is WISPr, do the following steps 3.1) Parse the embedded <ssid> from the PAC gateway response 3.2) Query the the manifest_url/page_url bound with this <ssid> 3.3) Send system message 'wispr-login' along with WISPr xml to those apps we queried in (3.2). If any of 3.1/3.2/3.3 fails, go for original captive path, too. 4) When an app is uninstalled, removed the entry from WISPr database. 5) (THIS IS OPTIONAL and open for discussion.) If I were the WISPr app developer, I would implement the app like the following: a) Prompt the user to ensure wifi is enabled and disallow the user to proceed until we detect wifi is enabled. We may bring up the settings page to improve the user experience. b) Use navigator.mozRegisterWisprNotification() to bind the app and the ssid. If the wifi is disable and we don't want to ever change wifi's state, we may need to pend the wifi association task in certain file and re-do the association the next time wifi is enabled. This can be implemented in the internal wifi state machine or system app.

Per discussion with vhcang and chucklee, we would like to provide WISPr capability for partner with the following minimum modification: 1) Add a new system message 'wispr-login' which binds certain certified permission. 2) While sending 'captive-portal-login' event, broadcast 'wispr-login' system message as well if the response is WISPr xml format. An WISPr app could implement such function like the following: 1) Use MozWifiManager.associate/forget to add the ssid it supports. 2) Use setMessageHandler('wispr-login', handleWisprLogin) to handle WISPr login. Also, if we are going to support "auto connect" (Bug 866718), partner could have their own default SSID list for "auto connect". Howei, could you please help make sure if our partner is fine with this kind of capability that we provide as well as the concurrent captive portal notification and WISPr issue? Thanks!

Hi Henry, yes, I think partner is ok with the capability we provide here based comments in bug 982384. Still, ni Wildfred to re-confirm.

Same as we discussed before - provide a platform level support that OEM/Partner can extend on to support Wispr. This is fine.