SpecialURL vs HandleURL

Ah, you’ve confused Session.Timeout with Application.SessionTimeout.

I suspect that WebApplication.SessionTimeout is actually what you’re looking for. This is the property that determines how long the app will allow a session to stay open after a browser disconnects. If you set it to zero, sessions will die as soon as the app thinks the browser is gone, and you’ll probably get lots of erroneous disconnects if using it on the internet because of latency issues.

OTOH, Session.Timeout is merely a timer on the browser that is used to tell the app when no keyboard or mouse events have occurred after a period of time. When that period of time has passed, an event (Session.TimedOut) fires on the application allowing you to do something about it. Think of a bank website where if you walk away from your session, it will eventually show a “dialog” which asks if you’re still there. If you don’t respond, they automatically log you off. Setting Session.Timeout to zero disables this feature.

[quote=190406:@Eric Wilson]Content and apps have converged and are converging with mobile devices.

Further, people want their state information to be preserved and work across devices and for different parts of their lives. Thus ordinary web servers are becoming more and more uneconomic to develop for as content becomes apps and vise-verse.

Also, the Web is full of legacy links that need further processing when they hit the web server. This needs to be handled smoothly.[/quote]
I’m not quite sure what you’re asking for, but I’d file a feature request if you’re wanting something we don’t offer. You can download the latest version of Feedback at: https://www.xojo.com/download/extras.php

HandleSpecialURL was years ago, but HandleURL was just 6 months ago and they address very specific requested things. For instance, we used HandleSpecialURL and HandleURL to manage the API calls for our XDC iOS app, the XDC iOS registration app and for the Passbook Web Service.

i’m still not clear as to why the combination of a web app and serving direct files through HandleURL (or using a separate server like Apache) doesn’t solve your issues. There’s no reason that you can’t serve regular HTML, CSS, Javascript, images, etc… directly through HandleURL, but it really is like dealing with a raw web server. It just serves files.

If you want session persistence between HandleURL and a WebSession, you’ll need to build your own mechanism for doing so at the moment.

Greg, thanks for the timeout tutorial. Really appreciated it – very useful to have them both and know the difference.

Mixing different technologies together – HTML, Java, CSS, images, files, helper apps etc etc etc produces multi-language and multi-server coding, testing, configuration and maintenance costs which increase with every new target and/or server platform one must support. In this regard, virtual servers are getting cheaper every day whereas hiring more and more employees is not. Mixing different technologies together is also very time consuming, requiring lots of meetings and planning and risk, making an online business far less agile. Furthermore, client-side solutions expose a lot more IP.

I think often the business case against trumps the technical reasons for such mixed solutions. While these may appear cheaper to run on the server, and make the dev team feel very clever, overall they can provide false economy and carry significant risk and opportunity costs.

That’s partly why I’m using Xojo for content-laden apps.

Thanks again,

Eric

Antonio Rinaldi said on another thread:

Can’t you use:

Request.status=302 Request.Header("Location")=<where you want to redirect> return true

And it seems to work OK for redirecting.