If we intend to provide support for polling it means the notifications need to be kept in memory. 

- What constraints do apply in this case? (I.e. TTL and MAX notification count?)  
- How does the design of this approach allow us to transition into a push based mechanism?  

Overall I am not sure a poll based solution adds any value to the current architecture. This is what we already do and it doesn't require any interim format, i.e. we directly poll for the existence of server resources. But maybe I am missing something here?

Regards, Heiko


On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <jmesnil@redhat.com> wrote:

I've updated the doc[1] to focus on the web console use case and the minimal requirements it has.

I wrote a simple plain HTTP API (no WebSockets, working with cURL) that should be enough for the Web console to handle notifications.

Since it's HTTP only, the console would still have to poll but:

1. It will have few well-defined HTTP resources to poll
2. There is an explicit contract for the notifications instead of extracting information from the different responses it get from the server.

This API should be suitable to http-based clients and when undertow is available in AS7, we could provide a WebSocket upgrade on its URL endpoints to push notifications to the browser.

jeff