Details
-
Type:
New Feature
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-4.0.0.GA, 4.1
-
Fix Version/s: EE-4.2.0.GA
-
Component/s: JavaScript Client, Push Library
-
Labels:None
-
Environment:ICEpush JavaScript Bridge, ICEpush Core
-
Assignee Priority:P1
Description
Instead of lazily adding the ice.notifyBack to the listen.icepush requests upon registering for cloud push and resulting in the eventual server-side NotifyBackURI representation, we should introduce new .icepush requests specifically for this:
1. add-notify-back-uri.icepush
2. has-notify-back-uri.icepush
3. remove-notify-back-uri.icepush
All these requests should be kept quite simple. The add request should at a minimum include the browserID and notifyBackURI as only the client-side is able to obtain the notifyBackURI. The response to the add request can likely just be a 200 OK or 204 No Content status message. The has request should at a minimum include the browserID. This request can be used by the cloud/mobile component to check if its browserID already has a notifyBackURI associated with it. The response to the has request can likely just be a 200 OK or 204 No Content status message indicating its browserID has a notifyBackURI associated with it, or it can likely just be a 404 Not Found status message indicating its browserID has no notifyBackURI associated with it.
For this both the client-side and server-side need to include support for these new .icepush requests.
1. add-notify-back-uri.icepush
2. has-notify-back-uri.icepush
3. remove-notify-back-uri.icepush
All these requests should be kept quite simple. The add request should at a minimum include the browserID and notifyBackURI as only the client-side is able to obtain the notifyBackURI. The response to the add request can likely just be a 200 OK or 204 No Content status message. The has request should at a minimum include the browserID. This request can be used by the cloud/mobile component to check if its browserID already has a notifyBackURI associated with it. The response to the has request can likely just be a 200 OK or 204 No Content status message indicating its browserID has a notifyBackURI associated with it, or it can likely just be a 404 Not Found status message indicating its browserID has no notifyBackURI associated with it.
For this both the client-side and server-side need to include support for these new .icepush requests.
On the server-side the handling of the following new requests have been added:
On the client-side the JavaScript Bridge has been expanded to allow for sending the new requests mentioned above.
Finally, ICEfaces has been augmented to include and support these new requests as well.
Marking this one as FIXED.