Re: Wifi/USB Tethering API Proposal

[Lucas Adamski]

Is this planned for 1.0?

Regardless, could we add this proposal to https://wiki.mozilla.org/WebAPI? Thanks!
Lucas.

On Jul 10, 2012, at 4:16 AM, Gene Lian wrote:

> Hi Philipp,
>
> Sorry for the delayed response.
>
> ----- Original Message -----
>> From: "Philipp von Weitershausen" <phil...@googlemail.com>
>> To: "Gene Lian" <cl...@mozilla.com>
>> Cc: mozilla-d...@lists.mozilla.org
>> Sent: Wednesday, July 4, 2012 5:49:07 AM
>> Subject: Re: Wifi/USB Tethering API Proposal
>>
>> On Tue, Jul 3, 2012 at 3:33 AM, Gene Lian <cl...@mozilla.com> wrote:
>>> Hi guys,
>>>
>>> This topic is created for the Wifi/USB Tethering Web API
>>> discussions. The back-end implementation has been supported by
>>> Vincent Chang and is under review (please see Bug 735547 [1]). In
>>> the next step, we need to define more accurate Web API behaviors
>>> at DOM interface layer. After some surveys [2], the basic features
>>> are listed as follows:
>>>
>>> 1. Tethering types (Wifi/USB)
>>> 2. For Wifi tethering settings
>>> a. SSID
>>> b. Security types (Open/WEP/WPA/WPA2)
>>> c. Password (for WEP/WPA/WPA2 types)
>>> d. Get the number of connected Wifi stations
>>
>> Do you mean s/stations/clients/?
>
> Yes, I mean the number of clients connected to the current tethering hotspot.
>
>>
>>> e. Limit the maximum number of Wifi channels
>>>
>>> Other advanced features for Wifi tethering settings would be:
>>>
>>> f. DHCP server IP
>>> g. Transmit power
>>> h. Auto shut-off
>>>
>>> Based on Vincent's design so far, we're using the existing Settings
>>> APIs to control the items 1 and 2.a-c. For the 2.d-h, we're
>>> planning to expose a new set of Web APIs to enable them.
>>
>> Why can't 2.d-h not be covered by the Settings API?
>
> That sounds reasonable. However, for the item 2.d please see my concern as below.
>
>>
>>> Some questions:
>>>
>>> 1. What is the standard of whether a feature should be put in the
>>> Settings APIs
>>> or new APIs? For item 2.d, it is obvious we need a new API to get
>>> that information. But how about others?
>>
>> It could be a read-only setting. Bit of a hack, but it feels silly
>> creating another API just for that.
>
> As my best understanding, the Settings API is aimed for supporting static information setting, which can be saved in the database when shut-down and restored later when power-up. Right? If the number of connected Wifi clients is dynamic (depending how many clients are connected at that moment), is it still suitable to use the Settings API? Or that's why you mean "bit of a hack" here?
>
> Thanks,
> Gene
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Philipp von Weitershausen]

I'm trying hard to prevent inventing a Web API for this... but if we
do, we'll add it for sure.

[Philipp von Weitershausen]

On Tue, Jul 10, 2012 at 4:16 AM, Gene Lian <cl...@mozilla.com> wrote:
>> > Some questions:
>> >
>> > 1. What is the standard of whether a feature should be put in the
>> > Settings APIs
>> > or new APIs? For item 2.d, it is obvious we need a new API to get
>> > that information. But how about others?
>>
>> It could be a read-only setting. Bit of a hack, but it feels silly
>> creating another API just for that.
>
> As my best understanding, the Settings API is aimed for supporting static information setting, which can be saved in the database when shut-down and restored later when power-up. Right? If the number of connected Wifi clients is dynamic (depending how many clients are connected at that moment), is it still suitable to use the Settings API? Or that's why you mean "bit of a hack" here?

Yes, that's why I mean "bit of a hack". The settings DB might save a
value, but we can ensure that it's always the right value after start
up.

Alternatively, we can use system intents. That would be cleaner, but I
don't know how far along these are. I will inquire.

[Gene Lian]

Thanks Philipp for the reply. Some quick questions as below.

----- Original Message -----
> From: "Philipp von Weitershausen" <phil...@googlemail.com>
> To: "Gene Lian" <cl...@mozilla.com>
> Cc: mozilla-d...@lists.mozilla.org
> Sent: Friday, July 13, 2012 7:56:25 AM
> Subject: Re: Wifi/USB Tethering API Proposal
>

> On Tue, Jul 10, 2012 at 4:16 AM, Gene Lian <cl...@mozilla.com> wrote:
> >> > Some questions:
> >> >
> >> > 1. What is the standard of whether a feature should be put in
> >> > the
> >> > Settings APIs
> >> > or new APIs? For item 2.d, it is obvious we need a new API to
> >> > get
> >> > that information. But how about others?
> >>
> >> It could be a read-only setting. Bit of a hack, but it feels silly
> >> creating another API just for that.
> >
> > As my best understanding, the Settings API is aimed for supporting
> > static information setting, which can be saved in the database
> > when shut-down and restored later when power-up. Right? If the
> > number of connected Wifi clients is dynamic (depending how many
> > clients are connected at that moment), is it still suitable to use
> > the Settings API? Or that's why you mean "bit of a hack" here?
>
> Yes, that's why I mean "bit of a hack". The settings DB might save a
> value, but we can ensure that it's always the right value after start
> up.

I would appreciate if you could please give me a hint or keyword that is there any feature using this kind of logic (read-only setting)? If there is no such a one, no worries! We'll try to work it out ;)

>
> Alternatively, we can use system intents. That would be cleaner, but
> I
> don't know how far along these are. I will inquire.
>

Sounds interesting! The system message (a more formal name from system intent) has just been supported by Fabrice last week. One thing I'd like to clarify here: do you mean we can send a system message from Gecko to directly notify Gaia's callbacks when the #clients is changed (instead of modifying the attribute in settings API)?

Besides, no matter we decide to use settings API or system message, it seems it's more like Gecko's responsibility to watch the dynamic change of #clients. Right? I mean why not just providing a querying function that Gaia can call periodically?

[Vivien]

At the moment I don't think 'read-only' settings exists.

>> Alternatively, we can use system intents. That would be cleaner, but
>> I
>> don't know how far along these are. I will inquire.
>>
> Sounds interesting! The system message (a more formal name from system intent) has just been supported by Fabrice last week. One thing I'd like to clarify here: do you mean we can send a system message from Gecko to directly notify Gaia's callbacks when the #clients is changed (instead of modifying the attribute in settings API)?

I don't really system this kind of System Message because applications
will be able to subscribe to it and will be wake up on a change of the
number or clients. I don't like the Settings hack neither but it seems a
good compromise until there is a proper way to do so.

[looking for new opportunity ~~~~ Vincent]

Hi there,
I listed the settings path for wifi/usb tethering here for your reference. Most of these settings path are used in Bug 735547 - support USB tethering.

My question is should we use "tetheirng.status.result" to indicate the result when user click enable/disable tethering button, and also use "tethering.wifi.stations.clients" to indicate the number of clients connected to out hotspot ? Or should we create DOM APIs to support it ?

tethering.usb.enabled, [bool] enable/disable usb tethering
tethering.usb.ip, [DOMString] ip address of usb interface
tethering.usb.prefix, [DOMString] network prefix of usb interface
tethering.usb.dhcpserver.startip, [DOMString] start ip address of dhcpserver pool
tethering.usb.dhcpserver.endip, [DOMString] end ip address of dhcpserver pool

tethering.wifi.enabled, [bool] enable/disable wifi tethering
tethering.wifi.ssid, [DOMString] wifi hotspot's SSID
tethering.wifi.security.type, [DOMString] hotspot's security type. It should be one of "open", "wpa-psk", and "wpa2-psk".
tethering.wifi.security.password, [DOMString] password when security.type is "wpa-psk" or "wpa2-psk"

tethering.wifi.ip, [DOMString] ip address of wifi interface
tethering.wifi.prefix, [DOMString] network prefix of wifi interface
tethering.wifi.dhcpserver.startip, [DOMString] start ip address of dhcpserver pool
tethering.wifi.dhcpserver.endip, [DOMString] end ip address of dhcpserver pool
tetheirng.status.result, [DOMString] used to indicate enable/disable tethering result, can be "success" or "fail".
tethering.wifi.stations.max_client, [DOMString] the maximum allowed wifi clients to connect to our hotspot.
tethering.wifi.stations.clients, [DOMString] current connected wifi clients.

Best Regards
Vincent