If by "logged in", you mean "showing up in the Other Users nodelet", that is because it is cached. As "presence" is a fragile concept with HTTP anyway, as HTTP itself is basically stateless, I wouldn't put too much weight on the accuracy of the Other Users nodelet anyway.
| [reply] |
Yep - you're dead right, I was indeed using the presence of my monicker in the Other Users nodelet to imply my being logged in.
Presumably, because the page is loaded afresh on logout, the nodelet must be cached elsewhere i.e. other than the users' i.e. my, browser, otherwise I/the user would see the contents of the nodelet as last displayed (all those hours ago:-) in the browser.
A user level that continues to overstate my experience :-))
| [reply] |
It isn't just that the nodelet is cached. Even if you got a brand spanking new rendition of the Other Users nodelet contents, it would still show you as "logged in" if you had just recently "logged out". The caching of the nodelet content is required to explain why you might not be listed immediately after you log in, though.
It wouldn't make much sense for the act of "logging out" to be what removes a user from "Other Users" (for one, logging out from one browser doesn't say anything about how many other browsers I'm still logged in via). Certainly, a great many users of this site almost never "log in" (enter their password) nor "log out". Users visit PerlMonks either anonymously or as a particular user. Visiting as a particular user (without having flagged your usage as "for ticker access", that is, presumably non-interactive use or alternately "cloaked" use for whatever reason) counts as "having been logged in recently" (short for "having visited recently while logged in").
What Other Users shows is simply users who have visited recently (obviously, not anonymously). After you log out, you have still visited recently (you have to visit in order to click the "log out" link, I think).
There are technical problems with having Other Users be up-to-date every time it is displayed with up-to-date information about relative idleness. Last time I looked at this, a long, long time ago, I was worried about the cost of adding an index to a fairly large table on a field that would be constantly being updated. And I've certainly seen bottlenecks related to this feature. But thinking about it now, I believe an index would be a net win despite the constant updates, even if we don't start re-rendering Other Users frequently.
But I still don't want an "idle" time shown in the nodelet. I think that would put too much emphasis on visitor's habits and in too much detail. The nodelet already communicates "idle time" by answering "have they been idle for more than a few minutes?". If you want more information on idle time, visit the monk's homenode. But note that even that information is not very accurate if the monk has visited recently, as that information is pulled from the node cache and we don't want to invalidate the cached copy of your user object every single time you load a page.
| [reply] |
Certainly. -- E. Schrodinger.
----
I Go Back to Sleep, Now.
OGB
| [reply] |
Questions about the caching of the Other Users Nodelet are so common. As we're still getting these, maybe someone could make About the Other Users Nodelet even cleaner?
| [reply] |
I agree, someone probably could, and should.
OTOH, if the question comes up that frequently, perhaps it should be addressed by a FAQ.
| [reply] |
How is it possible for people to not understand that a nodelet's contents are cached when it ends with "As of 2009-10-02 20:45 GMT"? Probably because they don't even bother to read to the end of the nodelet. Will they then read a sitefaqlet? Seems unlikely. I don't see this as a problem that needs to be "solved", though. Trying to prevent all "stupid" (or "unnecessary") questions just leads to one's own unhappiness. :)
If site documentation is unclear or incomplete, updates are, of course, appreciated.
| [reply] |