autoreload

[dschick]

Hej,

I guess it is genneraly possible to reload a logbook/entry in the browser in case its content was changed/added from somewhere else.

Would this be possible with eloy as well?

Best

Daniel

[johanfforsberg]

I have actually been thinking a bit about this. It's a fairly complicated question, I'd be happy to discuss it a bit here.

Firstly, what's the main purpose of the feature in your opinion? Is it mainly to make sure that the UI is up to date without having to constantly reload the page, or is it to prevent "edit collisions" where two people are trying to do the same thing? I think the feature should be able to solve both those cases if done properly. Are there any other cases I'm missing?

With regards to reloading, I'm unsure whether it's a better idea to reload the page or to just bring up a notification like "there are new entries, reload to see them". I feel like automatic reloading could be quite annoying if it happens while someone is using the application. It's also fairly tricky to do in a smooth way, since there are many corner cases.

My thinking so far is that the simplest implementation, at least on paper, would be for the clients to periodically (say, every 5 s) ping the server for changes since the last ping. It's simple because it's just a normal REST endpoint. But it also has some problems. I think either the client needs to send a timestamp of the last time it pinged, so that the server can know what updates to send, which raises problems about clock synchronization etc. Or the server needs to keep track of the clients to know when they last pinged, which again complicates things. Also, at some number of clients, the continuous pinging might become a performance problem (although that seems fairly unlikely given the intended purpose of Elogy as an internal tool).

Another solution would be using some "server push" technology such as websocket or SSE. Then whenever something happens on the server, it pushes a message to all connected clients. This would be a lot more efficient and could be very fast, but since flask is not asynchronous and might be running in multiple processes behind a webserver, it's at least not trivial.

Cheers!

[dschick]

Hej,

thanks for these details.
Indeed it would be the most elegant way to push changes from the server to any connected clients.
Since flask seems not to support that, I am also a bit stuck.

A periodic refresh would be fine, but it needs to respect any editing via the webclient.

Best

Daniel

[johanfforsberg]

Flask doesn't support it out of the box, but there are solutions using e.g. gevent, but that requires changes in how the application is run, which might get tricky. Another alternative would be to use a solution based on an external dependency such as redis, which handles client subscriptions, and then the flask app pushes updates there. But that would add more moving parts to the system, again making it more complex.

I think I will have a go at implementing a basic "ping" feature and see if I can get it to work reliably. Then, if for some reason that doesn't solve the problem, we can look into something heavier.