What y'all want is not a page server, but rather a message server. Step back and think for a minute. The reason it works on UseNet is that the killfiles and marking are done by the local client. The newsgroup server itself has no clue about what you have read, what you don't want to read, or anything about you at all for that matter.

Now step into the html server realm. The pages are generated on the server. What you are asking for is for the pages to be generated with custom values that you want under your control. That means that you have to send the information back to the server to indicate that an individual message, thread, or forum is in a certain state (read, kill, etc...). Now multiply that by an open-ended number of users, and the database server has to start keeping track of a lot of stuff (which is why we got into a compromise solution in the first place).

What you really want is not an stateless http message forum. What you are asking for is a smart client. One that goes beyond the realm of browser based messaging. Now Scott could (and probably will) add some individual message atrtibutes per user in the future. But this is no way a natural result of stateless solutions. Indeed, if perfection is what you're aiming for, than your are using (a). the wrong protocol - http; (b) the wrong message passing - html; and (c). the wrong client (ie, mozilla, lynx, whatever).

Beyond UseNet, the other alternative is to use RSS or ATOM feeds. Serve the messages up as RSS feeds and let the clients grab, present, and filter the information in whatever manner they do desire. Of course, that leaves the onus on the client to perform these client specific items. Really, you shouldn't be bugging the person distributing the messages. The person should not be in the act of performing your housecleaning chores. The bottom line is that y'all are asking for stuff that you shouldn't even be bugging Scott about in the first place. You're asking him to make your life easy, not realizing that this is not the primary goal of a server based solution.

Before y'all mention UseNet kill files one more time. Realize that it's the client, and not the UseNet Server, that performs these chores. Instead of bitching to Scott about these stuff, why don't you rewrite your on fricking clients to read the pages and perform whatever it is that you want with the data?

In the meantime, I'm sure Scott would be more than willing to admit that zIWETHEY was a kludge written with immature frameworks, with as much intention for Scott to learn the software, as it was a service to satiate the people that bitch and moan about the state of the user control.

In other words, Scott made the source code available to one and all. If'n you don't like the way it works, then either help Scott in a technical fashion, or write your own client to grab the pages and knock yourself out. If you think it's so easy, then get busy.

....I'm having too much fun saying how impossible it is. :-)

The protocol is just a bunch of page requests. Other than identity, the login doesn't maintain other state info. If you want to mark a specific thread as killed, then that thread to be killed has to be built into a name/value pair and sent off to the server as a page request. When it gets there, the information must be paired up with the user that's logged in and saved to a table that contains all such requests going back in time. Means that if you ever want to kill a thread, there must be a table that contains all the threads that you want to kill.

In addition, software has to be written to pair that information up with the generation of the pages themselves. (Not to mention that there probably has to be an interface where you can view all the threads that you have killed, and unkill them - users tend to hit the wrong buttons).

As Admin indicates, it can probably be done. What I take exception to is that this is natural (or in any sense easy). Once you get beyond a forum level, then the possible combinations of users, kill forums, kill users, kill subthreads, kill messages, unread messages, etc... gets to be a lot of information. Attaching attributes to each user for each message is not a simple matter. To do it, you have to start thinking about compression techniques and compromises. First level of compression is simple - if the user has no kills on the message, don't store attributes for that user. Second level of compression is relatively easy, if the user has marked all messages read, then just store the date/time of the last read message (which is where the line was drawn to begin with).

Now, how does the compression work beyond that point? Well, given that Scott stores these things a Nested Set, then a kill thread or a kill subthread would work by essentially having a table that keeps the message number of the top message in the thread and the point of kill within the thread (the two are the same if the thread as a whole is killed). So on any message you output, you check to see if the message or the Nest Left/Right don't have a hit (NOT IN())).

And then you have to worry about whether it's the thread or the individual message that's being killed. If it's the individual message, then you only kill the message not the subthread.

And then you have to check whether the user wants to receive messages from that forum. Which means you have a different attribute or table related to forums, as opposed to the individual threads within that forum.

And then you have to have an attribute associated with individual users that you don't wish to view. That kill of the individual must have the option of either (a). killing the individual's message; or (b). killing the individual's message and all responses in the subthread to that user.

And then you have to have a way for end users to update that kill list, such that they can bring back messages, users, forums, etc.

And then you have to mark each message individually as in an unread state (or vice versa). That information must be stored in a table, and wiped clean when the message or forum is marked read as a whole (which brings up the point, do you mark the thread or the individual message as read, and is that really a different operation).

Yes, all of this can be done, as Scott can probably attest. But it takes time, processor power, patience, and a lot of tests to do it. More power to Scott, when he gets the time. Just don't say that the solution was obvious or bloody simple if he pulls it off. After all, there's a lot of html based forum software that sucks much worse than the present zIWETHEY software.

...I quit smoking a couple of days ago, so my thoughts are not necessarily properly filter, sequential or coherent. :-)

The one thing you have going for you in a compressed scheme is that most users won't have a lot of individual unread messages (or killed messages) for an extended period of time. In fact, everytime you want to mark (or kill) a message, there has to be a roundtrip to the server. So, unless something really bugs you, or you really really want to come back to a message later, you'll probably not hassle with micro-managing the stuff. This should mean that you'd be able to compress down to a much more manageable scal of data, and as long as it doesn't overly bog down the normal queries it would be feasible.

One other note, if you're gonna kill an individual, you may want to kill them on an individual forum basis - perhaps I don't like what a person has to say about Politics, but they happen to be the best person to talk to about Linux.

As for scoring, I'd think you'd need a much larger population of both users and messages to make it worthwhile.