I don't really know. dodgygeezer did some magic and I've never really spent the time with it to work out how it works.

It's definitely cookie based. I guess that it saves the number of "old" comments on an hourly basis and shows the difference when viewing the front page.

I've been thinking about "unread" comments too, but I've yet to wave it at the powers that be. I'd prefer it that way, but there may be a super good reason to have it as "new" comments.

My understanding is that it is cookie-based and counts the number of comments added to a thread in the last x amount of time (the same as MeFi does). Number of unread comments would be better, of course, but would be orders of magnitude harder to implement, I imagine.

It shouldn't be harder to implement at all. In fact, it should be easier.

I'm wondering why metafilter, etc don't do it that way. There's maybe some social reason I haven't figured on or a gotcha my myopic eyes can't see.

Plus - Keeping an unread comment count would make it simple to implement a metafilter style "your latest comments".

What am I missing people?

I don't think you're missing anything, mate. I urge you to go on. It won't hurt at all. People will think you are cooler as a result. Big boys did it before. Even if you break it, nobody will notice. Dodgy did it, and that's why everyone likes him. Girls like boys who implement changes to the DOM based on the cookie model. Or something.

(I'm doing this wrong, amn't I?).

Seriously though, I don't know how MeFi works when you're logged in, but perhaps it only works that way because it always has. Seanyboy's comments seem to offer a couple of reasons for the suggestions above being feasible at least, right?

i'm so very sorry

And so you bloody should be, mate.

(And I'm just talking cricket here, but you are in danger of getting me started).

dodgygeezer: I'll just reiterate this bit: "or a gotcha my myopic eyes can't see"

My Boss knows full well my inability to correctly determine how complicated these things are. "Yeah - Full CMS in our crappy 2ndGen language. I should have that finished by the end of the day."

I'd rather it showed "unread comments" meaning it's counting the comments posted since I last visited the site/thread.

It's always seemed to me that the "new comments" counter has been rather odd/off. Sometimes it appears to update the count when I visit a couple hours later and sometimes it remains the same even when I visit 24 hours (approx) later. That could just be me - either it's just my perception (and I'm wrong) or reality due to my browser, I guess. (I sincerely hope this last paragraph made sense.)

I wasn't being flip, I'm genuinely sorry for a dodgy (heh) bit of code.

If I remember correctly, It's quite stupid really. The site creates a cookie that contains two time stamps: the time you last visited the site and the time the cookie was last checked. It then counts the number of comments on each thread since your last visit. Now, in theory it should only maintain a half hour window in which it counts visits more than half an hour old but that never quite worked for some reason - you refresh the page and it rewrites the cookie.

Really the two stamps belong in the database but for some reason that I can't recall, I didn't do that (I nearly did but never finished the code).

I came by the two date stamp solution on my own and being a bear of little brain it took me a long time to work out. When I did it I thought it was kind of dumb but was just pleased I had something that worked. Anyway, later on I read a thread on Metatalk where mathowie revealed how he did it and it seems he was doing the same thing I had (except in the db, not cookies).

Make of that what you will.

Anyway, unread comments is an interesting idea however it'd require a value stored for every user for every thread - and that's every thread that ever existed ever, ever. Where as the above method only requires two values per user.

If I do some very rough maths (the only kind of maths I know):
1000 users x 1000 threads x 4 bytes = 4 MB
1000 users x 2 dates x 8 bytes = 16 KB

Not that disk space is that big a deal I guess. Oh wait, I've probably got this all wrong. Sigh....

Don't threads close after a certain number of days? You wouldn't need to store a value for those threads, because there are no new comments, which would make things more manageable, wouldn't it?

I really rely on the "new comments" function because of my sporadic attendance here and it more or less works for me (with the same issue that deborah noted), but it would be way better if it could be calculated on the last time I visited that thread, which could create some complications with loading the index page or archives pages couldn't it? It would have to look up the flags for each thread on the page.

While we are talking comment-related ponies, the "my comments" function in MeFi is way useful for tracking responses to comments. Also, could the page return to the comment you just posted, rather than taking you back to the top of the thread? I compulsively check after I have posted a comment to make sure that my comment actually got posted and currently have to scroll all the way to the bottom (I know I'm not the only one that does this, so don't laugh!). Also, this would mean you could immediately see comments posted while you were typing/previewing.

You could do it the other way round, dodgy. Assume every comment has been read, and not show anything for those. Then all the db has to track are the comments made since the user's last visit. If their cookie knows when they were last here, all that has to be done is count the number of comments made (as dg points out, for open threads only) in each thread and display "x unread" where we currently see "x new".

If anyone's interested, phpBB has this feature (along with many more), is open source, and has an active community discussing how it works. (I'm not suggesting using phpBB, rather nipping over there and stealing stuff to use here).

How I planned on doing it...

When a user reads a thread, it stores the userid, the thread id, the date and the number of comments for that user. Not all users read all threads, so I guess that 4MB should be cut right down.

When displaying a post, the number of unread comments is shown as the (number of comments - the number of stored comments)

If space becomes an issue, assume all threads more than a month old have been read & delete all usercount records more than a month old.

Rather than try and create convuluted SQL statements linking the new table to posts, I planned on popping all this in a separate commentcount class.

This means that any post not read will show the total number of comments as unread (semantically correct) and any post read will show the number of unread comments.

The class will contain the following:

function NewCommentsFor (userid,postid,currentcomments)
procedure UpdateComments (userid,postid,currentComments)

and this should provide the functionality I need.
The biggest problem I can see with this is that I'll have up to 40 extra SELECT statements every time the page is refreshed. I don't know if that'd be a problem.

You, sir, are a legend.

You lost me after the "... on doing it" part, but it sounds like a fucking excellent idea.