Suggestions for tracking new posts in forum script

CMallette

Hello,
I am wondering what is the best way to track unread posts in a forum script. I've looked at a few forum scripts to see how they do it, but they use a method I don't like.

After looking at phpBB, XMB and vBulletin's sources it end up showing me that they track the users by adding the topic id and the timestamp of the last time they read that topic inside a cookie each time the user reads a topic.

I find this to be a very bad way especially due to the size limit a cookie can handle.

Is there another way of doing this? I was thinking about MySQL, but then again if the forums were very active I would have a huge table for nothing.

Any ideas?

yelvington

You're right to keep this out of cookies -- a very bad place to put such information. After all, what happens when the user goes to a different computer, or uses a different browser?

Put it in the database. When it comes to database tables, "huge" generally is not the problem you think it is.

Tracking unread messages is THE most important "enhancement" to any message system. Read "PLATO: The Emergence of Online Community" by David Woolley:
http://www.thinkofit.com/plato/dwplato.htm. He describes when and how the concept was added to the earliest conferencing systems. It's unthinkable that a Web-based system would omit it, a quarter of a century later.

I generally use a concept that dates back to the very early BBS era; I think I saw it in early Citadel code and in Tom Jennings' PUP software (an offshoot of Fido). For each collection of messages (forum, room, whatever you call it) you have a "high water mark" record for each user. This is fairly simple to implement in a modern SQL database. It allows you to select where id > highwater.

Your maximum number of highwater records will be num_users * num_forums ... not a number that is going to bother a database.

CMallette

Originally posted by yelvington
You're right to keep this out of cookies -- a very bad place to put such information. After all, what happens when the user goes to a different computer, or uses a different browser?

Put it in the database. When it comes to database tables, "huge" generally is not the problem you think it is.

Tracking unread messages is THE most important "enhancement" to any message system. Read "PLATO: The Emergence of Online Community" by David Woolley:
http://www.thinkofit.com/plato/dwplato.htm. He describes when and how the concept was added to the earliest conferencing systems. It's unthinkable that a Web-based system would omit it, a quarter of a century later.

I generally use a concept that dates back to the very early BBS era; I think I saw it in early Citadel code and in Tom Jennings' PUP software (an offshoot of Fido). For each collection of messages (forum, room, whatever you call it) you have a "high water mark" record for each user. This is fairly simple to implement in a modern SQL database. It allows you to select where id > highwater.

Your maximum number of highwater records will be num_users * num_forums ... not a number that is going to bother a database.

I just read the PLATO text and it turned out to be a good read 🙂.

What exactly do you mean by "high water mark"?

yelvington

Assuming your messages are serially numbered, a "high water mark" is just "the ID of the last message I read in this forum." You could do the same thing with timestamps rather than message IDs, if you prefer. Depending on how you built your data model, IDs might be faster.

Let's say you have a model where there are separate tables for rooms (forums), users, and messages. You need one more table. In one system I built, the highwater table looks like this

CREATE TABLE hiwater (
uid int(11) DEFAULT '0' NOT NULL,
roomid int(11) DEFAULT '0' NOT NULL,
messageid int(11) DEFAULT '0' NOT NULL,
KEY uid (uid, roomid)
);

So the logic is:

Find the messages where the room (forum) matches the current room, and where the message ID is greater than the current user's highwater mark for this room.

And don't forget to UPDATE (or INSERT, on a first read), the data in the highwater table, based on the last message ID of your retrieved bundle of messages.

CMallette

Sounds good however, if there is many new posts and the user reads the newest ones all the ones below that one will be marked as read using your technique.

yelvington

Right ... presumably if the post is requested and fetched, it has been read.