This looks very cool and the list of people involved is very impressive. I can see it being useful for apps with web and mobile clients.
What I found to be missing is some comparison to JMS. I can see many differences but also some commonalities. Especially since JMS implementations have some support for slow message consumers [1].
At my previous work we dealt with lots of live data from monitoring and in order to cope with slow consumers we started to look into conflation. Would be interesting to see if this project includes conflation support in the API.
This spec is total overkill. First, you don't need to conflate a pubsub interface with async streams. Two totally different problems. Second, async streams are easy:
2 comments
[ 2.5 ms ] story [ 11.7 ms ] threadWhat I found to be missing is some comparison to JMS. I can see many differences but also some commonalities. Especially since JMS implementations have some support for slow message consumers [1].
At my previous work we dealt with lots of live data from monitoring and in order to cope with slow consumers we started to look into conflation. Would be interesting to see if this project includes conflation support in the API.
[1] http://activemq.apache.org/slow-consumer-handling.html
http://stackoverflow.com/questions/21143996/asynchronous-ite...