new NotificationAction(peerIdentifier, connectionType, actionType, ecdhForLocalDevice, addressBookCallback)
Creates a sub-type of the module:thaliPeerPoolInterface~PeerAction class to represent actions for retrieving notifications. We MUST default ActionState to queued. We are explicitly assuming that all created actions will be added to the queue.
Parameters:
| Name | Type | Description |
|---|---|---|
peerIdentifier |
string | |
connectionType |
module:thaliMobile.connectionTypes | |
actionType |
string | |
ecdhForLocalDevice |
Crypto.ECDH | A Crypto.ECDH object initialized with the local device's public and private keys. |
addressBookCallback |
addressBookCallback | An object used to validate which peers we are interested in talking to. |
- Implements:
- Source:
Fires:
Members
(static, readonly) ActionResolution :string
Records the final outcome of the action.
Type:
- string
Properties:
| Name | Type | Description |
|---|---|---|
BEACONS_RETRIEVED_AND_PARSED |
string | The beacon values were successfully retrieved and parsed. |
BEACONS_RETRIEVED_BUT_BAD |
string | A connection was successfully created to the remote peer and a HTTP request was successfully delivered and responded to with a 200 but the beacons were not parsable. |
HTTP_BAD_RESPONSE |
string | A HTTP response other than 200 was returned. |
NETWORK_PROBLEM |
string | We weren't able to successfully create a network connection to the remote peer or we were able to create a connection but we weren't able to complete the beacon HTTP request. |
KILLED |
string | The action was killed before it completed. |
(private) actionState :module:thaliPeerAction.actionState
The current state of the action
Type:
- Implements:
- Source:
Methods
kill()
In addition to the inherited behavior also make sure to fire the module:thaliNotificationAction~NotificationAction.event:Resolved event.
- Implements:
- Source:
start()
Once started we MUST make a HTTP GET request to http://[hostAddress]:[portNumber]/NotificationBeacons. Make sure to set the TCP/IP timeout using suggestedTCPTimeout.
The logic for the GET request MUST asynchronous read the response to the GET request and ensure that it is not beyond a prefixed maximum size. Note that node does not validate that the length of a response body and the content-length header match so we MUST read the response in chunks asynchronously and if the total data read exceeds our predefined limit then we MUST abort the request object.
If we do get a successful beacon response then we MUST submit the beacon stream along with ecdhForLocalDevice and addressBookCallback to the module:thaliNotificationBeacons.parseBeacons method.
When completed fire module:thaliNotificationAction~NotificationAction.event:Resolved with whatever value makes the most sense.
Note that if we receive a kill method while waiting for the response then we MUST call abort the HTTP request, set our ActionState to KILLED and fire off a Resolved event.
Open Issue: Is abort truly synchronous? In other words is it ever possible to call abort, get back a response and then still have the response object show up? I should hope not.
- Implements:
- Source:
Events
event:Resolved
When the action has completed this event MUST be fired. If the action was able to retrieve the beacon
Parameters:
| Name | Type | Description |
|---|---|---|
actionResolution |
ActionResolution | Explains how the action was completed. |
beacon |
module:thaliNotificationBeacons~ParseBeaconsResponse | If actionResolution is BEACONS_RETRIEVED_AND_PARSED then this object will be returned. If the beacons were parsed and there were no values directed at this peer then the beacon object MUST be null. |