going asynchonous with JSF?

The main idea behind jsf is to have a layer of abstraction in the description and the handling of user-interface-components. The components in the component-tree itself are (conceptually) independent of their visual representation on a particular human interface device.

In reall life this fails shortly - shure you can write additional renderkits and render wml or pdf instead of html. Doing so you can get rid of quite a lot of behaviour that using the standard html-renderkit imposes on your application. But if you intend to do it a bit different than the traditional request/response-processing there's little support for this in the framework.

JSF 1.2 is completely synchronous. You send a request in, go through the lifecycle and get a response out. You can alter the lifecycle and view-handling to support Ajax (as e.g. dynamfaces of project jsf-extensions does by implementing the avatar priciple). But one principle remains the same - you get exactly one response per request.

Shure - this is how http is designed to work, but when looking at concepts like Comet you see that todays web-applications are no longer bound to this limitation. While having multiple Ajax-requests sent to a jsf-page without nessesarely updating anything in the browser is pretty straighforward the other way around (sending multiple responses to the browser without receiving a request from the browser for each response first) seems to require some fundamental enhancements of JSF.

What is required:

* While it's outside the scope of JSF, first of all support for Comet-style communication is a prerequisit. While it's not going to be in the standard before Servlet 3.0 there are allready some (proprietary) implementations (e.g. Grizzly does a nice job here)

* Access to a pre-existing component-tree of an existing user-session programmatically on the serverside including restoring, altering and saving the state correctly.

* Syncronisation of component-state with the browser through the asynchronous channel - even if the state is completely stored on the server the browser should at least track versioning information. If not doing so, there's no way to detect that the visible page and server-side state are out-of-sync. (Which easily happens if the user happens to press the browsers back- or reload-button).

Not a requirenment for asynchronous communication but desirable to complete this vision:

* Allow for queueing Events on components programmatically from outside the request-response lifecycle in such a way that these events are stored with the tree and broadcasted the next time the lifecycle is executed.