Hi!
Am 04.08.20 um 18:40 schrieb Rafał Miłecki:
> On 04.08.2020 09:43, Andre Valentin wrote:
>> Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
>>> On 31.07.2020 13:02, Andre Valentin wrote:
>>>> this is really great stuff. It would help me to get forward with my wifi
>>>> controller.
>>>> Could it be possible to subsribe to multiple sources to limit the
>>>> connections to ubus?
>>>> 2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand
>>>> right.
>>>
>>> I'm happy someone finds it useful!
>>>
>>> If you mean hostapd.* objects, that's right. That would require you to
>>> use:
>>> /ubus/subscribe/hostapd.wlan0
>>> /ubus/subscribe/hostapd.wlan0-1
>>> /ubus/subscribe/hostapd.wlan1
>>> /ubus/subscribe/hostapd.wlan1-1
>>>
>>> For subscribing to multiple objects we would need to:
>>> 1. Stick to GET due to the way EventSource works
>>> 2. Pick some more generic URL
>>> 3. Adjust output format ("event" and "data" fields)
>>>
>>> So my guess would be something like:
>>>
>>> $ curl
>>> http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
>>
>> Good idea!
>>
>>> event: hostapd.wlan1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan0-1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan1 status
>>> data: {"count":7}
>>>
>>>
>>> Regarding parsing events stream, event names with spaces seem to be OK:
>>> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
>>> field value can use any scalar value other than line break char.
>>
>> Why do you need the status there, is it part of the standard?
>
> That was meant to separate object name from notification name.
>
OK, I understand.
>
>>> We should use some special character as separator of object name and
>>> notification name. It must be something that ubus doesn't use in any of
>>> them. Should space be OK? Or should we use some more fancy char? I
>>> quickly tested space and it seems to work well in Firefox and Chromium.
>>
>> Oh, I'm nut sure. But I think space is fine.
>>
>> Did you use a special uhttpd version. I couldn't apply your patch to the
>> uhttpd in openwrt master.
>
> There are few more uhttpd pending patches that I sent, see:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=5824&state=*&q=uhttpd&archive=&delegate=Okay, will give it a try again at the weekend. Kind regards, André
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
