Closed Nutomic closed 4 years ago
Yeah, of course there are no "notifications" for http, but the websocket does need a way of for example getting new comments that http clients are creating. This means that the chatserver singleton needs to be passed in to the http layer, so that room (IE post) messages can be sent to the people currently in there.
This is far in the future, but I'm planning on doing a restructuring / re-scoping of a lot of the websocket code #445 . Right now, I'm only correctly doing websocket in a single post (it is the main chatroom after all), but really there should be several scopes (such as community subscribers receiving CreatePost
, and parents receiving CreateComment
for someone who replies to them. For both posts and replies, I'm doing repeating fetching (really hacky and not the way websocket should be used)
As @Nutomic adds federation code, we're finding that this is also necessary for activitypub endpoints too. IE, an activitypub inbox post requires an websocket update, so that it doesn't have to refresh the page.
Working on this right now. There's probably a way to do this properly with actix actors, but I don't know how to do that, so I'm just passing in the entire chat server instance.
Right now the documentation seems kind of hacked into the websocket and api code. As far as I can see, both systems are completely seperate from each other, so they can notify the same user twice (over websocket and email). On the other hand, websocket clients wont get notifications about actions done through the http api.
So I propose we take all this notification logic, and move it together in the same module.