Alexandrie's envelope icons work...

glad to know I'm not the only one w/ a mean icon fetish... hehe
nice work Alex!

The icons do make it much easier to keep track of the threads.........but I think the fact that the msgbrd is much faster has more to with it.

am i the only one who finds that those lovely little envelopes reset at random on some of the threads?

I find that on my home PC they are tracked differently than on my work PC. Therefore, I assume that my message board history is tracked by a cookie rather than being tied to my user account. Could that be what you're noticing, feline?

nope

on only one machine some of the envelopes manage to reset themselves now and then.

proably just need to format and then burn this machine *sigh*

The evelope icons uses cookies to track which messages you have read. Initially there was a new cookie being created for each message. Unfortunately with IE there is a 20 cookie limitation so I changed the cookies to create Sub Items under a single cookie.

Yesterday I just completed some of the cookie changes (the skin library) to prevent this from happening. So hoepfully from here on out it shouldn't clear itself anymore (fingers crossed).

Like the envelopes, really nice.

Is there any practical advantage using cookies to keep track of read threads over using a table in the database? It must cause havoc for those people using more than one machine.

I've just re-read that, and it sounds like I'm criticizing. I'm not, I'm actually pretty interested in how this thing works.

The big disadvantage to using a database in this case is the amount of data that would have to be stored. Considering that there is close to 300000 users on wincustomize. Everytime a thread was read I would need to store two pieces of information. So thats two datafields for each thread for each user. That amount of data could add up quite quickly.

Hmmm... good point.

/me goes away to rethink his whole stragegy

even though there are 300000 users on WC i highly doubt that all 300000 even touch the message board. there is, in reality, only a select amount of people who interact. therefore, because of this, it would cause minimal impact to use a table to store this information.

in fact, it would improve the users experience because most of us browse from multiple locations and therefore doing this would afford us the ability to properly "track" the forum.

session variables, which are subsequently saved to a table, are very easy to implement and do not require that much space.

Well jark, that's the method I'm currently putting together for my forums - session variables and a table matching users to messages with last viewed time/date. Without 300,000 people to test them though, whichever method I use will be nothing but a vaguely educated guess.

Using session variables is, IMO, a bad idea...especially on a high traffic site. Since a seperate server thread is created for every session, scalability becomes an issue - the more concurrent users - the more threads - the slower the server performs (unless you're using .NET - state management is vastly improved). A happy medium might be to use cookies to store the data locally (as is done now) - and serialize this to the database at some point (Session_End, maybe). When a user logs in, the database could be queried and the cookie re-baked for their current machine. This would ensure that a users 'status' would follow them - as well as cutting down 'per-thread' database access.

Just a thought

deviantART is a high traffic site that makes use of session variables without any performance degredation based on their use.

Well I'm using ColdFusion 5, which apparently is pretty good with session variables with large numbers of concurrent users. I think I'll stick to what I'm doing for the time being. I can always change my approach once it's had some testing.

Anyway... what was this thread about?

Ah yes! Nice icons Alexandrie!

I bet it performs slower that it would without them . It's all relative, I guess. I've got a couple high traffic sites (130+ transactions/sec) that are very much affected by session variables. Most developer publications (that I've read, anyway) advise against their use for just this reason.

T-Man - So hoepfully from here on out it shouldn't clear itself anymore (fingers crossed).

sounds good