I kinda missed this thread, probably due to the work week that was
going on simultaneously :/
Anyway, at the same work week, Jonas and I also came up with an API to
represent a mobile data connection:
https://wiki.mozilla.org/WebAPI/WebMobileConnection. I would suggest
that we try to make these APIs look similar as much as possible. Some
of this may as well be bikeshedding, though I think developers would
appreciate consistency -- I know I would.
Some points inlined below:
On Mon, Feb 20, 2012 at 2:08 AM, Jonas Sicking <
jo...@sicking.cc> wrote:
> Here's what I was thinking as a simple WiFi API:
>
> interface WiFiManager {
What is the intended API name of this object? navigator.wiFiManager?
For SMS, Telephony, we just do navigator.sms, navigator.telephony,
"manager" bit, so I would suggest we stick with that convention and do
navigator.wifi or something similar. Weird camel casing (even though
perhaps technically correct) is asking for lots of frustrating typos.
Another data point: WebMobileConnection, I initially saw it as an
excention to navigator.connection, but perhaps it should be more than
that. Then again, we could create a new "connection" family and do
navigator.wifiConnection.
> DOMRequest getNetworks(); // request.result set to JS array of wifi
> networks in range
WebMobileConnection calls this listAvailableNetworks, but getNetworks
is shorter and probably just as clear, so I'll change
WebMobileConnection.
> DOMRequest connectTemp(any parameters); // request fires success if
> successfully able to connect, error otherwise
What's with the "Temp"? Does it stand for temporary? If so, why?
I like the idea of passing an object for parameters. I think we should
definitely spec it out, probably containing lots of optional
attributes.
Another question: where do we expect wifi keys to be stored? In Gecko?
In the UI (e.g. Gaia), perhaps via settings API, perhaps in its own
little DB? Basically, do we expect the UI to simply store all that
information itself and then pass it into connectTemp() each time we
connect? This would have pretty severe implications, because it would
mean that the UI would also have to watch networks becoming available,
connecting to them when they do and are "known", etc. This *feels*
like a Gecko-level task to me, but I'm not sure. My initial idea of
the system would have been a bit more like we do HTTP Basic Auth:
Gecko prompts the UI if it doesn't know credentials yet, otherwise it
just connects.
> any connected; // JSON object (frozen) which contains info on the
> connected network
In WebMobileConnection this is a bool, with "operator", etc. providing
the information about the current connection. Should we adopt a more
nested approach for WebMobileConnection, too? Or live with the
inconsistency?
> Function onconnect; // Fires event when we connect to a new wifi network
> Function ondisconnect; // Fires event when we connect to a new wifi network
In WebMobileConnection you suggested "onconnectionchange", and then
consumers would have to look at the individual state flags. I would
certainly advocate for this as well. In particular, I imagine more
states than just "connect" and "disconnect". At least "connecting"
would be good for UI feedback.
As for signal strength, please see WebMobileConnection. We also had
some good discussion on that in
https://bugzilla.mozilla.org/show_bug.cgi?id=729173. I haven't looked
into the Wifi pieces yet on how we get the information, but again,
consistency across APIs would be great (e.g. a number ranging from 0
to 1.0).
Lastly, I think Wifi also allows you to get the signal strength of
networks you're not connected to currently. So the question is whether
maybe signal strength shouldn't be exposed on WiFiManager but on the
"connected" object, or whatever. This would mean making that object
more complicated than just being frozen JSON, though.