I don't see notifications as a bidirectional thing. I look at it this way:
sync:
C: "Please send me notifications regarding /foo=bar to id=123"
S: "OK, will do"
C: "Please send me notifications regarding /baz=zap to id=123"
S: "There is no such resource, sorry"
...
In the meantime, you have:
async:
C: "Notifications for id=123"
S: "/foo=bar changed ..."
S: "/foo=bar changed ..."
...
(connection broken - cell phone went into a tunnel)
C: "Notifications for id=123"
S: "/foo=bar changed ..."
...
It seems a very clean mapping, cleaner than web sockets tbh, and a sight
simpler architecturally.
I do not see async notifications as a good solution for long-running
operations since those are essentially synchronous. I'd rather see a
server-side solution for that (even the outliers like restarting a
server). Trying to make these asynchronous is sort of the path of most
resistance, in that we're borrowing complexity we do not need.
On 02/27/2013 01:43 PM, Heiko Braun wrote:
SSE are asynchronous, but unidirectional. Whereas websockets are
asynchronous and bidirectional.
Enabling push through SSE, clients could use a combination of
request/response for the main communication (i.e. execution of
operations, reading the model contents, etc) and SSE for the notifications .
Using websockets we could move all client communication to one paradigm.
But do we need it?
Currently have cases where clients keep polling for system state changes
(i.e. server restart, deployments, etc). Typically the things that take
some time to complete. So I am wondering if these cases could benefit
from an asynchronous bidirectional communication channel. But I guess
this depends on how the DC processes management operations and if
asynchronous responses would fit into the picture.
/Heiko
On Feb 26, 2013, at 6:37 PM, David M. Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
> I don't know, it seems like overkill. I think
>
http://html5doctor.com/server-sent-events/is probably a better option
> than web sockets or polling as it is supported in the browser with a
> simple API and doesn't require a lot of complex server-side support.
--
- DML