Feature Request: WebSockets Server for Remote Lyrics & Control

[michaelhthomas]

Having a Websockets server implemented to access lyrics, status, etc. would be a much better approach than constant polling in the web remote and android apps, and would also give a more standardized control api. It also seems pretty trivial to implement a WebSockets server in Java.

[berry120]

When we first started work on this, websockets weren't desperately well supported hence the decision to go with polling. While I'm not against a websocket based system now in theory, in practice we'd have to run the two side by side so that older clients could still connect, which limits the advantages somewhat.

I'll leave this open for now and consider it a bit more, but my main concern here is the backwards compatibility element.

[matejkobza]

I believe there is not much to be afraid with websockets. It's just different technology being used for pull of the lyrics. The changes are populated from server side instead of client pull every 2-3seconds if there is an update. Every common browser nowadays supports this feature.

Do you mean third party integrations from other applications?

[berry120]

The issue isn't with supporting old browsers, it's with supporting old versions of the android and iOS apps already out there.

If we were to switch to websockets now, it'd mean those current apps would suddenly cease to work without explanation - we'd have to upgrade the apps themselves, and then hope people installed the updates to those apps. In theory that's fine, in practice it'll almost certainly cause confusion.

We could run the two systems side by side for a while to ensure a compatibility window - but again, that's more complexity.

[micahlt]

@berry120 Kind of the same issue in #369 - it might be helpful to establish a boundary line of exactly how much compatibility you want to strive for and for how long.

[berry120]

@micahlt Going to be much more strict about backwards compatibility in this issue than the other one I'm afraid. The other issue I'm reasonably flexible on as it only involves old browser compatibility. This involves old app compatibility (unless we run two servers, which I'm not keen on) and ideally I really don't want older versions of the Quelea app to just stop functioning after an upgrade with no explanation - that could really hurt users that don't know they need to upgrade.

Not against moving to a websocket based server in principle, if we were writing from scratch now we would have done that. But we'd need to carefully think of an upgrade path, we'd need to all approve it, and a PR we accept for this would have to involve both the desktop app & mobile apps, with @ArvidNy being able to test & publish new versions (and I'm not sure of his availability at the mo either.)

[MistaWizard]

I built a Node server to connect to Quelea’s built in webserver. I use server sent events instead of websockets to send to the front end. It’s at least an option in the interim that has worked well for us.

https://github.com/MistaWizard/Quelea-On-The-Web