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).
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
