Details
- Reviewers
- None
- Group Reviewers
Restricted Project
none yet
Diff Detail
- Repository
- rK kolab
- Branch
- dev/push
- Lint
Lint Skipped - Unit
No Test Coverage - Build Status
Buildable 47778 Build 18135: arc lint + arc unit
Event Timeline
src/app/Backends/Events.php | ||
---|---|---|
45 | In the firebase case the notification_token is a separate token that identifies the channel to the device. We could implement the same abstraction I suppose:
There's currently a 1:1 mapping between notification tokens and deviceid, so it doesn't buy us anything atm, but may provide more flexibility in the future? | |
src/app/Http/Controllers/SSEController.php | ||
64 | I don't think there is a way to reliably detect dropped connections without sending some data (there's tcp keepalive, which sends data, but I'm not sure we can rely on that here). If we want to guarantee delivery of notifications there needs to be a protocol for acknowledgement from the client and retransmission otherwise. | |
src/routes/api.php | ||
210 | We can get the user from the guard, but if we want device/client specific notifications I think we need an id (The companion app code uses device_id rather than client_id, and until we have multiple clients on the same device they are probably going to be the same). I don't think we initially have device specific notifications, but one could foresee the need based different purposes. I suppose we could map this to oauth scopes, but then again, we already have the companion app entry with some config, so I suggest to leave the id in there. |