Page MenuHomePhorge

WIP: Server Side Events
Needs ReviewPublic

Authored by machniak on Jun 19 2024, 3:23 PM.
Tags
None
Referenced Files
F16763460: D4803.id13754.diff
Fri, Nov 8, 12:44 PM
Unknown Object (File)
Sat, Nov 2, 9:57 PM
Unknown Object (File)
Wed, Oct 30, 12:26 PM
Unknown Object (File)
Sun, Oct 27, 2:32 PM
Unknown Object (File)
Thu, Oct 24, 3:18 AM
Unknown Object (File)
Sat, Oct 12, 5:00 PM
Unknown Object (File)
Sat, Oct 12, 3:05 AM
Unknown Object (File)
Sat, Oct 12, 1:21 AM
Subscribers
Restricted Project

Details

Reviewers
None
Group Reviewers
Restricted Project
Summary
Test Plan

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

machniak created this revision.
  • Workaround KTOR client bug, add development commands to send push notifications
mollekopf added inline comments.
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:

  • The device registers with a separate "client_id" as notification token.
  • We use the client_id that is stored in the notification token instead of the device_id.

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.