There is a "big-picture" perspective that we need to keep in mind here, that being that ICEfaces as a whole is targeted at Java developers who do not want/need to become JS experts. Thus, even though we are adding JS APIs I believe that we should lean toward an API approach that will be the most transparent to Java developers with potentially weak JS experience. It does our users no good if we following JS best-practices that they will be unfamiliar with. The ultimate goal is to enable them to be as productive as possible without requiring a bunch of JS experience, best-practices knowledge, etc.

Having said that, I prefer MIrcea's approach of separate functions for each event type for it's increase in transparency/usability. I do think that we should be able to identify "up front" what the necessary event types should be for something as fundamental as the JS bridge functions. Note that we can revise these through the Alpha/Beta pre-release process as required also. It might make sense to group the connection related functions together via naming, such as OnConnectionError, OnConnectionUnstable (I prefer OnConnectionWarn), etc.

A few more notes, the "addOnXXX" is horrible. The "add" offers nothing additional in the way of comprehension and serves to muddle up the distinctive parts of each function name, so I vote strongly to lose it entirely. The "onX" pattern is succinct and easily understood by reviewing a few of the function names together, and doesn't get in the way of the unique bits of information about each function.

For events where having a pre/post event makes sense, how about using pre/post as per normal industry practice: OnDOMUpdatePre() OnDOMUpdatePost. This also has the advantage of putting the tense qualifier at the end of the function name, making related functions group together nicely in a list. It might be better to just have one function with a parameter for Pre/Post, with the default being the most likely case: OnDOMUpdate( Callback) - meaning post, or OnDOMUpdate( "Before", Callback) for pre.

Removed onSessionExpired callback registration. In order to properly invoke this callback Glimmer server-side code should control the session expiry process.
Instead of relying a special command for session expiry notification the server-side code could send an update notification to all the views when the session is expired. Each view will issue a request for acquiring the corresponding updates but instead of the updates it will receive a session expiry custom error page.

Here are the callback registration function that ICEfaces bridge is currently exposing:
----------------------------------------------------------------------------------------------------------------------------------------------
ice.onServerError(callback-function)

The registered callback function will be invoked when a server error is received by the browser either on the JSF form submit. The callback function receives the following set of parameters when invoked:

function callback(statusCode, responseText, responseDOM)

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onBlockingConnectionUnstable(callback-function)

The registered callback function will be invoked when bridge's hearbeat detects that the server doesn't responds in a timely fashion. The callback function does not receive any parameters when invoked:

function callback()

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onBlockingConnectionLost(callback-function)

The registered callback function will be invoked when the blocking connection is lost to the server. The callback function receives the following set of parameters when invoked:

function callback(reconnectAttempts)

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onViewDisposal(callback-function)

The registered callback function will be invoked when a view within the page is disposed, the view could be a portlet, an include or the whole page. The callback function receives the following set of parameters when invoked:

function callback(viewID)

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onSubmitSend(callback-function)

The registered callback function will be invoked when the form submit request is issued. The callback function receives the following set of parameters when invoked:

function callback(queryParameters)

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onSubmitResponse(callback-function)

The registered callback function will be invoked when the response corresponding to the form submit is received. The callback function receives the following set of parameters when invoked:

function callback(statusCode, responseText, responseDOM)

----------------------------------------------------------------------------------------------------------------------------------------------
ice.onBeforeUpdate(callback-function)

The registered callback function will be invoked before the updates are to be applied to the DOM. The callback function receives the following set of parameters when invoked:

function callback(updates)

----------------------------------------------------------------------------------------------------------------------------------------------

document describing the update format

Resolving the issue. Future enhancements or changes can go in their own JIRA cases.