Open nesium opened 5 months ago
I think we could use different resources for each tab, probably using sessionStorage
in the SDK to re-use the last-used resource for the current tab if the user just reloaded the current tab.
The connection flow would be as such: when the JS SDK starts, check sessionStorage
for the last resource value, if nothing then generate one and store it, if there's already one then reuse it. This would guarantee that each tab has a different resource, since sessionStorage
is local to the current tab, and persists in memory until the tab gets closed.
Slack allows parallel tabs with no problem, I believe we should do the same. The server would limit the maximum number of connected resources at some point anyway, preventing any user-induced "DOS" attack on the server.
IMHO this issue should therefore be moved to prose-core-client, however I acknowledge there's currently an issue w/ multi-tab Prose Web apps due to the resource re-use across tabs.
What happens if we start to display push notifications or what about the message sounds? What if I change my availability? I would have a different availability in different browser tabs - this would also affect the current cache implementation which is shared between tabs.
Would it be possible to share the same connection?
Indeed, we'd have issues there too. Push notifications can be worked out / de-duped if they come from the server using Web Push. Different availabilities is more of an issue indeed, but the same issue would apply to a mobile Prose app on eg. iOS, running at the same time as a Prose Web app.
True, although you would consider the web app and iOS app to be a different resource, so it makes sense that these have different availabilities. I would argue the same is not true for two different tabs of the same browser. My mental modal here is that a new tab/window is a tab/window of the same app, as it would be with a desktop app.
If you do not agree, what would be the benefit of using sessionStorage
over a random generated resource?
Benefit of storing the last resource is that if the tab is reloaded for any connection timeout reason at least this would ensure we’d replace the previous dangling resource as fast as possible with a new connection, instantly killing the previous one.
To summarize what we talked about in Slack:
If you open the webapp in another window of the same browser the connections in both windows fail. The reason is that the core lib reuses the resource id/name. I have seen that the Matrix web app detects that another connection is active and offers to disconnect it and connect from the new window instead. We could do the same.