Won’t the Xojo server kill the session if the client disapears (especially if it has dropped down to AJAX if WebSockets aren’t available) ?
Exactly what I was describing as thick client. I did not realize you had already used that technique for the XDC app.
Back in the early eighties I was working for the French network CalvaCom, a local equivalent of Compuserve. Since the thing was text only and as slow as everything modem then, we had apps for Mac, Apple II and PC that provided the UI on each machine with it’s particular look and feel.
The advantage of the thick client over any other session resume system is that there is no data loss while connectivity is out.
The load balancer will keep the connection alive since it’s the load balancer that is connected to the app and the browser is connected to the load balancer 
There are settings for load balancers to keep sessions open for a set period of time.
http://john-joyce.com/xojo-and-load-balancing-with-haproxy/
That’s not how this system works. Both the browser and the Web App expect to have pings from each other periodically. If the browser doesn’t hear from the server, it shows the “disconnected” overlay. If the Web App doesn’t hear from the browser for 3+ minutes, it ends the session. Adding a load balancer to the middle will not affect this.
What you DO get from the load balancer is that it will always send the browser to the same instance of the app, so if you have 2 or more copies of the app running on separate ports, they can all appear to be the same app.
FileMaker has a neat feature called “fmreauthenticate” for use on iOS and Desktop with FM Server when a user is disconnected. When you come back to the database, it just reconnects and leaves you right where you left off.
Maybe in Xojo a Session Timeout could be set for x seconds and if the user sees the “has gone off-line. Please try again later” message, the browser could try to reconnect to the session every x seconds until the Session Timeout expires?
It works like this:
[code]If your users will be using iOS devices, you may want to specify the fmreauthenticate[X] extended privilege.
FileMaker Go for iPad and iPhone allows multitasking. While using an iOS device, the user can answer a call or move to another app at any time. When this happens, FileMaker Go moves to the background and saves the state of the file.
With the fmreauthenticate[X] extended privilege, when FileMaker Go switches to the foreground users must re-enter the account name and password if the specified time limit [X] minutes has elapsed. For example, an extended privilege of fmreauthenticate10 allows the user up to 10 minutes away from FileMaker Go before reauthenticating is required. You can create as many of these extended privileges with different periods as you need and assign them to different privilege sets. Users can attempt to enter their account name and password five times before FileMaker Go closes the file.[/code]
Interesting Hal! Maybe it would work this way actually:
client side: If the client can no longer connect to the server, a dialog appears asking for your patience. The user can not do action (the client forbidden). The client saves this state (“wait”) in a variable. If the connection does not come back again within 3 minutes (or a lower limit, adjustable), the client closes.
Server-side: If there is no connection with the client, the session is still maintened 3 minutes. During these 3 minutes, if the connection with the browser returns again, the server checks that the client is alive and is in “wait” state. If this is the case, the server maintains the session and returns the current page to the client, so that the page to be updated and variables synchronized.
It is a small step, but it will already help many. Would solve the problem of the interim loss of data or WiFi connection. it would also solve the problem actually when the client closes as soon as you open another app on IOS, for example to send a text or answer a phone call.
So what do you do between the time when the server disappears and the browser notices that the server disappeared? Any user action during that time means that the browser and the server are out of sync. We can’t send a ping to the server (and get a response) fast enough to effectively “pause” the browser fast enough to prevent this from happening. Even if we could (like on a local network) we would be essentially flooding the network with keepalive info, leaving very little bandwidth of the communications that make the app actually work.
On the topic of converting XojoScript to JavaScript and running that on the browser… It has the same limitations as XojoScript has today… You can’t pass objects back and forth, so unless we converted the entire framework to JavaScript you would still be transmitting data back and forth. Even then, things like accessing a database would still require talking to the app on the server, and that’s where most of the processing is done in a typical web app.
We have done a lot of thinking about this problem over the years, and we have added a lot of experiments, but nothing has really worked very well for all scenarios.
Would it be possible to keep the session alive for the timeout period, show that the user got disconnected, and have a button reconnect to that session so they could pick up where they left off?
The client app already sends “long polling” requests right?
When the client app closes, that’s when this long polling (or a request due to a user action) fails?
What a difference between the display of a “The app must close” message and a “The connection is cut with the server, your current action has perhaps not been saved, please wait” message? In both cases, the message must appear quickly.
In the second case, the framework will continue the long polling for 3 minutes. If the request is successful within 3 minutes, the server returns the page in the browser so that the data are updated in the browser.
Ok, the last user action will perhaps lost (as in the first case) but at least the client stays connected. Ok, this is a trade-off. But do not be dogmatic. At least on option, and knowingly, we should have this type of functionality. It is to us and to our customers to make that choice.
The action or the user input is lost! Just like now. But trade-off is here. We know we have no offline mode and requests can not be cached in the Xojo framework. We know it. But there is an important need for the client to quickly reconnect when the network is available again.
I know that with this option, we would not have the same time information on the server. Some data will be more difficult to handle.
But again, in full knowledge of the facts, it would be good that we have this choice. Especially that there are several ways of developing a Xojo Web App. For example, in my case, the entire client app is developed with the SDK. I use very rarely the synchronized server variables. When I need information whose origin is related to the browser, the client sends to the server via the Xojo.triggerServerEvents.
Other people can also develop differently. It should not be assumed our needs.
If the connection is reestablished, a Session ‘Reconnected’ Event could be triggered. Then the developer could deal with how to handle the reconnection.
Some iOS app developers store info on the users last environment so if the app crashes or relaunches, they can restore their environment.
That said, we could do that now by storing a login cookie and then restore where they were when they reconnect. All they’d have to do is reload the page.
There is no difference, but we can’t guarantee that they’ll be fast enough in any case. Just think about what a typical web user does if something doesn’t respond right away… they start clicking buttons. Heck, that’s the reason that most order forms say “only click the Order button once or your card may be charged more than once.”
Long polling only works if there’s something to connect to on the other end. Otherwise you get a socket timeout error within a few seconds indicating that the server is no longer there.
Something to keep in mind… while the discussion we’re having here is about reconnecting when the server becomes unreachable and then is reachable again within 3 minutes, we should also be discussing the scenario of the server goes away permanently. Whether by the user leaving the cell network, the internet is down, the server is down or even if the app crashes and doesn’t come back. This is part of the reason this problem is so complex, because in this case I’d argue that you’d want the browser to indicate very quickly that the server was not going to be available for an extended period of time so that users don’t waste their time. We are trying to keep a good balance between these two scenarios and sometimes the path is just not so straightforward.[quote=218184:@Hal Gumbert]If the connection is reestablished, a Session ‘Reconnected’ Event could be triggered. Then the developer could deal with how to handle the reconnection.[/quote]
This is not a bad idea. You should file a feature request.
…and if your front end is an iOS app calling into an API through HandleSpecialURL and/or HandleURL then yes, this is very easy to do. Being that by default, the only code that exists in a user created web app is framework code, with no customization for individual user controls, we don’t really have a good way to store and keep the “state” in sync.
That’s what we do now. The session ID allows you to reconnect to an existing session.
So a trade-off would be for example to display a “Try to connect to the server” BUTTON on “Has gone off-line. Please try again later” PAGE?
The user can attempt to reconnect by clicking on this button. If the client can connect to the server before 3 minutes, an event is triggered on the server on the same session. If the client can not reconnect to the server before 3 minutes, the button will restart the app and therefore a new session when the server will be accessible again.
Yes, that would be a good improvement.
Thinking about it, it still seems to me simpler to remove the button and try to reconnect automatically every three seconds for example (if there was a network problem, not if the timeout is finished, of course). It is more professional. If the connection is in the 3 minutes, the event is triggered on the server. If the connection is after 3 minutes, app and therefore a new session is restarted.
But on IOS, when the user will switch to another application (eg to respond to an email) and will return to our application, the framework can automatically send reconnection requests or it will be frozen?
(https://xojo.com/issue/41057)>]<https://xojo.com/issue/41057>
The content :
Feeback 41057 - Trigger event on the server if the browser can reconnect to the server (Web Framework)
Currently, the browser closes the web app and displays a “The application has gone off-line” page when it can not connect to the server.
The idea is that from this moment, the framework tries to reconnect to the server every second for 3 minutes.
If successful, a “reconnected” event is triggered in the session on the server. The developer can then act if desired, for example by sending a page to the browser.
I added my point for the feedback case.
Thats sounds perfect!
[quote=218195:@Greg O’Lone]@Hal Gumbert That said, we could do that now by storing a login cookie and then restore where they were when they reconnect. All they’d have to do is reload the page.
That’s what we do now. The session ID allows you to reconnect to an existing session.[/quote]
Greg, when I go back to the app, I will get a new session. How can I proceed to reconnect to the session that was displayed before ?
Currently, if the user refreshes or goes back to the root url, a new session begins automatically. If the user redirects away from an app and then presses the back button, on the browsers that don’t disable JavaScript, we attempt to reconnect automatically.
The case we are talking about here is when a browser is temporarily unable to reach the server and then regains connectivity without interaction from the user. A good example would be a mobile user with an unstable wifi signal.
[quote=218966:@Greg O’Lone]Currently, if the user refreshes or goes back to the root url, a new session begins automatically. If the user redirects away from an app and then presses the back button, on the browsers that don’t disable JavaScript, we attempt to reconnect automatically.
The case we are talking about here is when a browser is temporarily unable to reach the server and then regains connectivity without interaction from the user. A good example would be a mobile user with an unstable wifi signal.[/quote]
Oh, so if I understand right, during the three minutes period after which the app ends the session, if the browser responds again, no new session is created and the existing one just resumes ?
Would it be possible to extend beyond that 3 minutes period ? That could be just what Olivier needs in his warehouse…