[PATCH V2 uhttpd] ubus: add new RESTful API

[Andre Valentin]

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é


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4052 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200805/6749b388/attachment.p7s>