[PATCH V2 uhttpd] ubus: add new RESTful API

[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.


>> 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=