Welcome Guest, Not a member yet? Register   Sign In
Forum system - how to track already read vs new messages, per user

I agree there is a possibility a lot of data will be retained, but you have to decide how accurate you want to make your read/unread status per user.

For the notify i again would go for a general user setting to let the user choose if none ,all new posts, a digest of posts or individual posts need notification. If the individual posts setting is chosen another table comes into play where you store the thread ids, post ids aren't needed here as you mentioned yourself.
I wouldn't put it in the read table because then you have the chance the notification setting will be removed if the table is cleaned for the user for some reason. You can set an expiration date on the read records but as long as the thread is open it can be revived.

Basically you have to encourage users to clean up after themselves if you want the most accurate data per users in balance with a good performance of the forum. You can do it for example by pointing out similar topics the user is notified of when an new individual thread is selected. If a user has read items older than a certain date you can show a message with a link that will remove those.

For sure .. it was always going to be an accuracy (of read/unread) data versus bloat .. it's only as I've started pencilling stuff in that the potential scale of bloat is becoming clear.

I'm happy to wear the risk of losing read-flags for a given user/thread, during clean-ups - and also forego the idea of offering digest/each-message/other-variations of notifications - as that's just way too complicated for my brain to deal with at the moment. It'd be nice, yes, and I think I follow the logic of another table to track posts, but for the moment, too much.

In part to address the bloat question, by putting an effective soft limit on the number of threads needing to be tracked, I'm thinking about locking threads that have been inactive for .. pick a number .. say 2 months. Old threads being resurrected is annoying for users at the best of times, so this is a handy two-birds solution I think. Once a thread is locked, any read of it would return a 'already read' for any given user. And the thread_lock() function would just go through and delete every row in the read-table where thread_id matches to affect that change. Sounds too easy.

Quote:You can do it for example by pointing out similar topics the user is notified of when an new individual thread is selected. If a user has read items older than a certain date you can show a message with a link that will remove those.

I don't follow this bit. I thought perhaps you meant when a user starts a new thread, they get told of extant threads with a similar subject - but no. You mean some reminder for users to update the read-table by visiting (or at least pretending to) a thread?

A clunky way I can think of for seeing if you read the post or not, is to have a LONGTEXT field in the db for each post that has userid_read. You could use explode and if the userid is there, the thread was read.

Note: I said this was a clunky way to do it, and only effective until you have over 100-500 users I would think.

jedd the removal of read threads depend on the content of the forum. On a tech forum like CI old means dead but if the forum contains bittorrent announcements that can be revived old means coma.

I think in the end the locked thread idea will be even bigger than the read table data because it can only grow. If you decide on date based cleaning mechanism i would set every users read date that is lower than to the date the cleaning takes place and remove all records in the read table for everyone.

Quote:You can do it for example by pointing out similar topics the user is notified of when an new individual thread is selected. If a user has read items older than a certain date you can show a message with a link that will remove those.
I was thinking about the notifications there. If a user want to get notified about a new thread a search should be made to find if there are other thread with similar content and queue the matches for deletion. This can clean the notify table.
Letting the user clean the read ids table was another suggestion, i'm sorry it caused confusion.

Okay .. got it now. It'd work if the user was fairly sensible, and was going to be reading lots of threads anyway, but if the user is not very sensible and/or doesn't track the majority of the threads, then the majority of the information kept about that user's message-read status across all threads will be (mostly) pointless.

I suppose a lot does come down to the nature of users. Dang it. Smile

The forum will be something I'd want to keep forever. I don't like the idea of nuggets of wisdom - wisgets? nugdoms? - being kept in forums, as they're notoriously hard to track down. It's especially frustrating for casual visitors who notice a Wiki link right next to the Forums link, and find the the former empty and the latter full of noise. (Most recent example for me - the MSI Wind (.net) site.) I'd like a technical approach that at least assists in the engineering solution to the social problem of getting people to 'manage their own data', as it were. Forcing deletion of threads .. is an interesting approach to encouraging users to cut-n-paste out any large, useful, insightful rambles they may have done in-thread and move them to a wiki .. but probably not very effective. At the moment I'm wanting to lock threads primarily because it's just irritating to have old threads resurrected, but very happy about the side benefit of making my message-read table leaner and better maintained.

Take your point about locked data being big compared to the message-read table, but absent a locking mechanism, the latter would always be a function of the former, which suggests something closer to a geometric than an arithmetic progression. While a lock mechanism certainly won't keep the size static - it'll reduce the rate of change of the growth.

So no-one actually knows of a library which does all of this for you?

Instead of moving parts to a wiki why not let the users bookmark posts and when the time has come to remove the thread leave the bookmarked posts and the thread record if there are any.

Then you can split up the search in recent threads and bookmarked threads. The bookmark search will be more useful i think because the content is filtered. If you allow it members can revive the thread as a new one based on the bookmarked item.

TheFuzzy0ne this goes beyond a library the stuff we are talking about has tentacles all over the forum code.

Give me a few more weeks. Wink

Longer response: a while ago I looked around at various auth libraries - and kind of decided on DX - but soon realised that it would require either a lot of munging to make it work with my member and group plans, or it would require me to mung my member and group arrangement. Similarly, I considered trying to rip out the guts from some extant forum software, but without even looking at them concluded that I'd have the same problem, only far more painful as the internals of a forum are less obvious (to me) than the internals of an authentication system.

I think it's a problem that you have already observed, elsewhere on these forums.

I'm not sure what my design goals are at the moment, which makes it harder. I'd like a nicer level of integration than you usually see on web sites with forums - where it's clear that they've tacked on a forum, and haven't even matched the theme to their main site. I'd like to be able to do links in the [ ] style back into other components of my site, make a 'quote' feature for putting into a wiki page rather than a forum-reply, a way of tagging forum threads with keywords that also match wiki tags, and so on. I reason that it'd be as much (if not more) effort to learn and then retro-fit someone else's base product, than to write my own and do it as I go.

Plus, I'm here for the Fun of it - this is not a paid project for someone else. If there was a commercial imperative I'd doubtless approach this differently.

My final observation - apart from some non-trivial logic & algorithm questions on implementation - writing a forum seems to be relatively easy. I say this because I'm not a programmer, or a DBA, or a web designer, and yet I got the skeleton of a forum, using 7 tables, up and going with just a couple of 'real days' of effort. If / when I am not embarrassed by this code I'll happily share it with anyone that wants it - but my gut feel is that, like every other 'drop in library' out there, it will simply be too much effort to wrangle into your extant codebase.

**Makes a sharp exit - stage right -->

Theme © iAndrew 2016 - Forum software by © MyBB