Right now there's no granularity to an application being synchronous versus asynchronous, it's all one or the other.

A developer might want to make one page asynchronous and another synchronous, for scalability reasons. There might only be some pages that benefit/require server push, so why pay the resource cost of always being asynchronous, when that page isn't even being used? Not only are there the server resources of sockets and threads, but also issues of bandwidth (constant ping/pong) for the client, particularly for mobile devices like the iPhone.

One idea for an implementation is to have a third mode called "automatic" that would default to synchronous mode behaviour, unless some asynchronous criteria is met, in which case it switches to asynchronous mode, while that criterion holds true. There could be a per page asynchronous rule, or an API that beans could hook into (possibly via annotations), or components could simply have an asynchronous attribute, or even self-describe themselves as asynchronous by their nature, like an inputFile component that is presently uploading. When the view is rendered, the [a]synchronosity of the page would be transmitted to the client side of the bridge, which would respond accordingly.

When done at the component or bean level, instead of just the page level, you get the added benefit that whether or not the developer is using redirect tags with their navigation rules, and so viewing a new page or just a new subset of an existing page, the bridge could still respond to the automatic [a]sync mode change.

Additionally, there might be a way to tie in the registration of an IntervalRenderer, so that while the RenderManager has an IntervalRenderer registered to a view, then that view would be promoted to asynchronous mode. If the registration happened in a request, then that would be in time for the RENDER phase of the request to switch the mode to async, and if it's not in time, say because they did it in some other thread or whatever, then that registration fact could still be looked up or be available to the selection criteria. The point is, we want it to be as automatic as possible, and allow for tuning parameters, but not require the user to have to deal with the minutiae.