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.
Attached client side changes. I also modified the response of HasNotifyBackURI servlet to always respond with a OK 200, the response body will contain the 'true' or 'false' string depending what the result of the test it is. I believe we do not need to carry procedure invocation concepts into the HTTP realm. Also code handling on the client side is much simpler and straight forward.