[eluser]jedd[/eluser]
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?
