We actually recently added support for using SSE as a method of receiving events. Within section 8.5 of version 1.5.0 of the Redfish Specification (www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.5.0.pdf), we allow for a client to perform a GET on a URI specified by a new property in the EventService called "ServerSentEventUri". All events generated by the service will be sent to the client on the open socket. So, with this mechanism, a client does not need to make a subscription, and wait for events to be published.
However, our mockup server tool does not support this sort of functionality. The mockup server is a very simple service that just provides single JSON files when a client makes a GET request.
I finally implement an SSE mechanism for the eventing. So, I have 2 more questions
1. Event Type : There is no "real" subscription, I mean the client does NOT send a subscription with needed Event Types. The only subscription contains the Event Destination, but no event types desired by the client. So when I send a message from one side, every suscribers receives every message, did I miss somehting ? 2. Should I implement a WebSocket (that dispatchs messages to all waiters) or an EventSource/emit from client side ?
You're correct in that there is no real subscription. When a client connects to the SSE URI, all events tracked by the service will be reported to the client. In this model, the client performs the event filtering when it receives data on the SSE connection.
Unfortunately I do not know how to answer your second question; ultimately you should be doing what makes the most sense for your implementation. I imagine you'd probably have a single source where events are generated, and that would be the place to push data to all open SSE connections.