https://sourceforge.net/p/xcat/wiki/Confluent_clientevents/Recent changes to Confluent_clienteventsenMon, 04 Aug 2014 02:57:59 -0000https://sourceforge.net/p/xcat/wiki/Confluent_clientevents/<div class="markdown_content"><pre>--- v1 +++ v2 @@ -1,3 +1,5 @@ +[[include ref=Design_Warning]] + Provide a means by which clients can cheaply have a channel to receive updates on changes as they happen, but not actively poll. This will be via some resource in the tree. It would behave in many ways similar to a console/session resource. Meaning it can be opened and data will come as it is available depending on the criteria used to initiate a new event session. For the socket interface, it's straightforward as we get to define the semantics just like the console interface. For HTTP interface, the client has to have a long-lived request as a hook for confluent to fire back data (just like console data in the console/session resource) </pre> </div>Guang Cheng LiMon, 04 Aug 2014 02:57:59 -0000https://sourceforge.netf359b634c153adf12402830bb7c81e48244d3340https://sourceforge.net/p/xcat/wiki/Confluent_clientevents/<div class="markdown_content"><p>Provide a means by which clients can cheaply have a channel to receive updates on changes as they happen, but not actively poll.</p> <p>This will be via some resource in the tree. It would behave in many ways similar to a console/session resource. Meaning it can be opened and data will come as it is available depending on the criteria used to initiate a new event session. For the socket interface, it's straightforward as we get to define the semantics just like the console interface. For HTTP interface, the client has to have a long-lived request as a hook for confluent to fire back data (just like console data in the console/session resource)</p></div>Jarrod JohnsonSat, 02 Aug 2014 00:29:11 -0000https://sourceforge.net526feff3b34e0726bdddc291e3e5fde05e2a377f