On 9/14/05, bruce <bedouglas@xxxxxxxxxxxxx> wrote: > > ben... > > i understand what you've stated, but i was under the impression that a > number of sites (etrade, etc...) can/do track who is/is not logged into > their sites.. and not just by some crude 'timeout' function... This might be possible to do with some client-side javascript. I think that eTrade and all of those sites are using an AJAX paradigm and so the client is periodically pushing requests onto the server (but just for the information that needs to be updated). Among other things I'm sure that users would be submitting the session ID that they have and eTrade can track if the browser session is still alive by doing this. However, all of this would be something to ask on a JS list instead of here. :-) Also remember that not all users will enable JS so you need to have backup functionality (i.e. rely on the timeout) so you will never have 100% accuracy, but the method described above will improve your accuracy (at the cost of extra HTTP connections) ... by your statements, you're pretty much saying that the only approach one has > to this issue is to utilize some sort of timeout function, and if you > don't > detect user activity after your timeout, then mark the user as no longer > being active, and proceed accordingly. this apporach doesn't allow an app > to > immediately know when a user has killed the browser. > > so, the question might be, how does one detect when a user has killed a > session/left your app? The timeout method is still the main way to do it... but with the addition of the AJAX methods you can have the client machine *push* updates into your user session. Once you've determined that the client is enabling JS then it is pretty safe to assume they will keep JS enabled for the life of the browser session. So when your site stops getting pings from the client you could kill their session. All of this said... unless you're using AJAX throughout the entire sit already I wouldn't mess around with it. IMHO it takes a lot of extra coding and the added benefit for something like improved user count isn't going to offset the costs of coding and extra HTTP connections when it goes live.
