[PATCH V2 uhttpd] ubus: add new RESTful API

[Rafał Miłecki]

On 04.08.2020 09:57, Jo-Philipp Wich wrote:
>> 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
> 
> To me it feels quirky to separate the path and the type of the event by space.
> 
> Personally I'd only report the type as "event:" and move the source path into
> the JSON data portion,

This seems to break hierarchy. I see correct hierarchy as:
1. Object
2. Notification type
3. Notification data

If we put type in "event:" and object path and notification data in
"data:" it seems unnatural.


 > or even omit it entirely.

I'm sure one may need to distinct notifications from wlan0 vs. wlan1.
That's probably not an option unless I missed something.


> Considering the design of the client side API:
> 
>     eventSource.addEventListener(type, handler);
> 
> Most use-cases probably want to register a handler for a specific event type,
> e.g. "status", and not N handlers to handle the different object path
> variations, so given the subscribe examples in the previous mail:
> 
>     eventSource.addEventListener("status", (ev) => { ... })
> 
> instead of
> 
>     eventSource.addEventListener("hostapd.wlan0 status", (ev) => { ... })
>     eventSource.addEventListener("hostapd.wlan0-1 status", (ev) => { ... })
>     eventSource.addEventListener("hostapd.wlan1 status", (ev) => { ... })
>     eventSource.addEventListener("hostapd.wlan1-1 status", (ev) => { ... })

I see how it simplifies JavaScript code though so I'm confused.

Should we maybe totally drop "event:" and just put everything (object
path, event type, data) in "data:"?


> Granted, one could use the `onmessage` event to implement a catch-all handler
> which is then filtering and dispatching according to the type, but even then
> string operations like split(), indexOf(), regex matches or similar would be
> required to match event types, that feels unelegant and not very performant.
I'm not sure if "message" event fires for *named* events (event: foo).