Sure, you can do this with dbm, but you might want to consider alternatives after thinking about the problem.

(I assume that by "login" you mean that they've been authenticated by the application, and not the OS, and that you've set a tracking cookie that you can reference whenever the user hits a page or invokes a script on the web site.)

As you've noted, to present the list of who is online in a given area you need to answer the question "which authenticated users have hit pages in this area within the last N minutes?" How to best do this depends on a number of factors, including how large your community is, what kind of peak traffic you expect, and whether you want to maintain data for more than N minutes.

Fundamentally, there are two approaches: you can keep your data (usernames) ordered by most recent access time, or you can update a field in records that are unordered with respect to access time.

In the ordered case, you start scanning the (ordered) records until the last accessed time falls out of range. Unless you expect to have large peaks visits, chances are good that you can keep a relatively short list of recent visitors, culling the list at update time. Assuming that the disk blocksize is 8K, and the average length of a username is 10 characters, you can safely keep up to 400 "username timestamp\n" records in a per-area flat file that you can read with a single disk access, and can update with a single access (if you truncate the file first). You may well have had more visitors within the past N minutes, but past some smaller number, I doubt that you're going to want to display that list on a webpage. (Consider the "Other Users" box to the right. It gets unwieldly after ~30 users.)

In the unordered case, you need to sequentially scan records, checking the last accessed time of each. This won't present any performance penalties for a small community (~1600 "name timetamp\n" records can fit into 4 disk pages in a flat file, and into a few dozen pages if you're using dbm or MySQL.)

Now consider that you're going to be doing an update for every page fetched. Update in the ordered (by access time) case is fast if you limit your bookeeping to the number of records that you're actually going to display. Update in the unordered case is also quick, assuming that your database is indexed on username.

So which is best for you?

Assuming that you have a large community, and want to keep as last-accessed time for each user, and are willing to limit the number of "recent" visitors you'll display to sane number, you might to well to consider a hybrid scheme: use dbm (or mysql) to maintain your user data including last-accessed times, and use a flat file to keep a short list of visitors ordered by last access.