One strategy for implementing this would be to display a registration page that immediately paused the push connection. The application would be configured so that Cloud Push could be sent a number of times without requiring Ajax Push confirmation.

The BridgeIt Console could itself provide this registration page (possibly customized for a given realm). The Console would also include a page for sending notifications via simple boolean configuration. No application pages would need to exist.

In some cases the application may establish an Ajax Push connection but not want this to disrupt the Cloud Push requirement of some notifications.

Technique using existing implementation:

• page with login adds user to pushgroup under username and forces page navigation
• push to group "username" will now result in a Cloud Push

To guarantee Cloud Push (even if the user is on a page supporting Ajax Push), notify.icepush can include the parameter "strategy" with values "auto" (default: attempt ajax and fall back to cloud), "ajax" (ajax push only), "cloud" (cloud push only). When strategy=cloud, ICEpush will immediately invoke the NotificationProvider associated with ice.notifyback for the PushID.

A related feature would be to allow the application to select the mechanism for the cloud push, such as email or SMS. The difficult here would be that the server application does not typically interact with each user's connection to allow it to set the notification mechanism directly.

To accomplish this feature (sending to a list of email or SMS endpoints) it might be more effective for the server to directly invoke an SMS or email sending mechanism.

This seems to be a duplicate of PUSH-403.