Add support for offline mode

[MoritzWeber0]

It should be possible to request a session, which can be used offline. This is helpful for situations where no reliable internet connection is available, for example in the train.

• Access to TeamForCapella will not be possible from offline sessions.
• It should be possible to run the session on Linux, macOS and Windows devices.
• There should be a framework with instructions to run a docker container. The docker container should be exposed via RDP or direct X11 Forwarding.
• The workspace will not be synced with the server. There will be a different local workspace (Docker named volume).

[MoritzWeber0]

One initial implementation idea:

• Add support for the Collaboration Manager as progressive web app: https://angular.io/guide/service-worker-getting-started
• Without internet connection the Collaboration Manager is very limited - only the Sessions tab should be visible. All other actions should result in a error message, for example "This feature is not supported in the the offline mode".
• The user has to install podman rootless. Detailed instructions have to be provided.
• The user has to install Python on the local system.
• The user has to pip install a small package, which will contain a "Podman runner"
• The library spawns a small fastAPI server on an available port with the same interface like the real backend server.
• The persistent session routes have to implemented - all other routes should return error messages.
• The library should add a binary, which is added to the PATH variable. Optionally, the binary should also be copied to the desktop.
• The user starts the "offline" Collaboration Manager by starting the Python library binary. The binary starts a fastapi server in the background, opens the PWA and passes the port on which the application is running.
• The PWA sets the endpoints properly and points to the offline version now.
• The user can start a session as usual. Session connection is only possible via direct RDP. Session termination also works as usual.
• The image has to be pulled before.

[Wuestengecko]

Just my two cents (feel free to ignore this first part - I'm quite inexperienced with web dev and can't judge the effort myself): If the user has to pip install and launch a server locally anyways, why bother making the frontend a PWA? Couldn't the local server just serve regular web pages which (mostly) look like the online collab manager? I imagine it could lead to some duplication of frontend code (which would be bad), but I also imagine the whole rerouting business when the upstream connection becomes (un-)available could also cause more than just one headache.

Another question: How would a user who has reconnected get data from the offline session back to the online collab manager? (I suppose it would use the offline version if launched from there, and try online if visited manually?)

[MoritzWeber0]

Just my two cents (feel free to ignore this first part - I'm quite inexperienced with web dev and can't judge the effort myself): If the user has to pip install and launch a server locally anyways, why bother making the frontend a PWA? Couldn't the local server just serve regular web pages which (mostly) look like the online collab manager? I imagine it could lead to some duplication of frontend code (which would be bad), but I also imagine the whole rerouting business when the upstream connection becomes (un-)available could also cause more than just one headache.

It's not just about the frontend code duplication - it's also about keeping the two frontends aligned. When there is a change in the frontend UI/UX, we would need to change both frontends (in addition to the two backend (local / server). There is a lot of stuff that we can make work offline, e.g., file browser and session termination. It would also be amazing to get the session viewer to work locally, but I don't think that we will ever run Guacamole locally.

I'd not care much about rerouting at all - this can be solved via simple switch (offline points to the localhost backend, online to the real server).

Setting up a PWA isn't much effort and the backend URL is a variable already, so this should be easy.

On the other hand, with an independent client we are more flexible in term of API changes (server side) and there is no need to install a PWA before (even though it should be simple task). Also, it might be a more stable solution.

Another question: How would a user who has reconnected get data from the offline session back to the online collab manager? (I suppose it would use the offline version if launched from there, and try online if visited manually?)

The workspace will not be synced with the server. There is a offline workspace and a online workspace. The user has to keep them in sync (most likely via Git).