Gimme a block button underneath everyones sn, PLEASE PLEASE PLEASE.

It would be sooo nice if I could just block the hell outta half the wolf web...please crazyJ, I'm begging you, this is ALL I want for Christmas, LET ME BLOCK...

1/12/2002 3:50:13 PM

haha i'll renew my premium if you do it

1/12/2002 3:58:37 PM

the problem with this is that if you blocked that person and other people respond to what they said, things start to not make any sense and you miss part of the conversation, and then people get confused.

1/12/2002 4:19:53 PM

I will sacrifice myeslf and be confused for the sake of missing a bunch of fuckin assholes postin retarded shit I dont care about, yes I will be confused instead of pissed, thank you...

4200 posts, sounds an awful lot like 420...

[Edited on January 12, 2002 at 4:32 PM. Reason : 420 i mean 4200]

1/12/2002 4:31:32 PM

oh no, not confused

like i'm not confused already

im with you mojo man lets rock the vote

1/12/2002 4:44:29 PM

Hell yea, I would have about 69 users on my non block list...man o man wouldnt that be nice...

1/12/2002 5:02:00 PM

The only problem with this is that it would require cookies to store who you blocked and I think there is a maximum cookie amount for each site. If you put this info. on the server it would take up a lot of space if everyone started blocking everybody else. But it would be rather server intensive because instead of just spitting out the contents of the thread it would have to go through each post and make sure that the person isn't in your block list. Have a lot of people doing this and it would severly bog down the server.

1/12/2002 5:16:39 PM

DOH, well then how about just me n Jackleg, we will pay you...

1/12/2002 5:24:18 PM

That would be a possible idea there. Add additional services for 'Super Premium' users. And charge a little extra to be a super. This might also help pay for the site some.

1/12/2002 6:02:45 PM

I would DEFINATELY pay more for this ONE option...plus I would bitch alot less seein as I can block anyone who pisses me off...

1/12/2002 6:50:44 PM

Quote :

"The only problem with this is that it would require cookies to store who you blocked and I think there is a maximum cookie amount for each site. If you put this info. on the server it would take up a lot of space if everyone started blocking everybody else."

1 bit boolean variable for each user, because they all have a user number. With 4000 users, the cookie would be half a kilobyte per cookie. Stop talking about shit you dont know shit about.

Quote :

"But it would be rather server intensive because instead of just spitting out the contents of the thread it would have to go through each post and make sure that the person isn't in your block list. Have a lot of people doing this and it would severly bog down the server."

A boolean variable is almost nothing compared to looking up the status name and number of posts, especially since when you find one, the rest dont take any more processing time to find.

1/12/2002 9:51:58 PM

hmmm.. #1 - this thing would never happen because it would disrupt the flow of conversation and lead to chaos. how can you reply to a topic (or another reply) without seeing all of the replies?

#2 - both of you guys are WAAAY off in how it would be implemented. why the hell would we try to put so much information in a cookie? until you have a clue into how i designed our session state management, arguing with each other is meaningless and will get you nowhere

and insaneman although i see MANY other flaws in your method, the primary one is that we couldn't just have an 4000 element bit array. we would need keys for each bit to identify the user it corresponds to. we coudn't keep the order static enough to not have a key. the key would obviously be the same primary key of the user table, the userID. this is a 32 bit integer. lets even assume we'll use a 16 bit integer. (16 bit userID + 1 bit boolean) * 4000 users = 8.5kb. unless we created our own serializable structure which even at the most efficient would still boost it by 10-20%, we would end up using a hash that would convert the 16bit userID to a string and the 1 bit boolean to a char and boost the size by well over 100%.

also for some reason you assumed that we would store a value for all users. why the fuck would we do this? if i were to do it with cookies, i would have one cookie value with userIDs delimited by commas. you would of course only store the userIDs that were blocked eliminating the need for even a boolean field. why the fuck would you store userIDs just to give them a false for being blocked?

the whole cookie system would only work for the machine that you were currently on. we would rather make it portable and associated with the user account rather than the computer. that is why i wrote a DB based session state module.

Quote :

"A boolean variable is almost nothing compared to looking up the status name and number of posts, especially since when you find one, the rest dont take any more processing time to find."

once again you have no fucking idea how our system works. bavander is a LOT closer than you are. first of all you should learn a little about RDBMS's. then you would be familiar with half of the terminology that roughly describes what you are talking about.

first of all we don't do any "looking up the status name and number of posts". we lookup the userID in a simple clustered index, then return the username, status name, and number of posts. anyways, when we "look up the status name and number of posts" we are doing a "join" between the user table and post table. doing a "NOT IN" where clause would be needed for excluding users from the query. this would require querying another table aside from the user and the post table. an "excluded user" table that would have a primary key of the requesting users userID combined with a user that would be excluded. doing this just as intensive as "looking up the status name and number of posts" because the portion of the "excluded user" clustered index being scanned will be the same (32 bit userID) but there will be many more rows. even if we don't use an "excluded user" table and implement it through cookies or some other sort of means, the NOT IN clause will add some overhead.

second of all we don't do any querying on 80% of our page views. we just dump straight from our preassembled cache that already has each row combined with username, number of posts, status, and post itself. this is a lot lighter on the system than doing filtering, joining, and paging on every request. applying a filter based on an array of rejected values would definetly add processing time to each request. it wouldn't exactly "bog down" the server, but it would make it work quite a bit harder

so insaneman, maybe you should "Stop talking about shit you dont know shit about"

1/12/2002 10:56:02 PM

Insaneman, why don't you just stft. I've been studying computers and programming/webdesign/misc since I was eight, always ahead of ALL of my teachers and professors. Hell, my asm proffessor in my senior year couldn't even do half the shit I can and he had a college degree. So, before you wanna acuse me of not knowing what I'm talking about, maybe you should consider just how much you know, or don't know.

1/13/2002 12:50:09 AM

Applauds Jake...

I think Insaneman's dick just shrunk...

1/13/2002 1:47:12 AM

Quote :

"1 - this thing would never happen because it would disrupt the flow of conversation and lead to chaos. how can you reply to a topic (or another reply) without seeing all of the replies?"

blah!

dude crazyj are you on fucking speed? thats like a 400 page reply you've got going on there

1/13/2002 1:59:30 AM

I dont think it would totally ruin the flow of conversation. Many times there are many many different conversations going at once...I personally dont like to conversate with the assholes I would block so I wouldnt be missing much...The only threat I could perceive is if this person learned that you blocked them then went on to talk mad shit all around your posts knowing you cant see them...

This is just a chance I am willing to take...

1/13/2002 3:07:00 AM

Quote :

"anyways, when we "look up the status name and number of posts" we are doing a "join" between the user table and post table. doing a "NOT IN" where clause would be needed for excluding users from the query. this would require querying another table aside from the user and the post table. an "excluded user" table that would have a primary key of the requesting users userID combined with a user that would be excluded. doing this just as intensive as "looking up the status name and number of posts" because the portion of the "excluded user" clustered index being scanned will be the same (32 bit userID) but there will be many more rows. even if we don't use an "excluded user" table and implement it through cookies or some other sort of means, the NOT IN clause will add some overhead."

This man is like a God to me
--John Cusack; One Crazy Summer

1/13/2002 3:56:58 PM

I dont give a rat's ass about blocking people. I just wanted to make bavander look stupid. but anyways...

Quote :

"and insaneman although i see MANY other flaws in your method, the primary one is that we couldn't just have an 4000 element bit array. we would need keys for each bit to identify the user it corresponds to. we coudn't keep the order static enough to not have a key. the key would obviously be the same primary key of the user table, the userID. this is a 32 bit integer. lets even assume we'll use a 16 bit integer. (16 bit userID + 1 bit boolean) * 4000 users = 8.5kb. unless we created our own serializable structure which even at the most efficient would still boost it by 10-20%, we would end up using a hash that would convert the 16bit userID to a string and the 1 bit boolean to a char and boost the size by well over 100%."

You are overcomplicating this. You have user numbers that go up to about 4000. No key is needed if the whole thing is loaded into the array in order. array[userNumber]. It doesnt take much system resources to keep 50 of these arrays loaded in server memory for those who are logged in.

Quote :

"also for some reason you assumed that we would store a value for all users. why the fuck would we do this? if i were to do it with cookies, i would have one cookie value with userIDs delimited by commas. you would of course only store the userIDs that were blocked eliminating the need for even a boolean field. why the fuck would you store userIDs just to give them a false for being blocked?"

because its only 500 bytes, it eliminates all that bullshit you said you would have to do in the first quote, and its much easier to implement

Quote :

"first of all we don't do any "looking up the status name and number of posts". we lookup the userID in a simple clustered index, then return the username, status name, and number of posts"

That is how I thought it worked.

Quote :

"we are doing a "join" between the user table and post table. doing a "NOT IN" where clause would be needed for excluding users from the query. this would require querying another table aside from the user and the post table. an "excluded user" table that would have a primary key of the requesting users userID combined with a user that would be excluded. doing this just as intensive as "looking up the status name and number of posts" because the portion of the "excluded user" clustered index being scanned will be the same (32 bit userID) but there will be many more rows. even if we don't use an "excluded user" table and implement it through cookies or some other sort of means, the NOT IN clause will add some overhead."

minor inconvienience. a character could be put at the beginning of the name column that tells the "join" to add a font color tag that blanks out the text

Quote :

"second of all we don't do any querying on 80% of our page views. we just dump straight from our preassembled cache that already has each row combined with username, number of posts, status, and post itself. this is a lot lighter on the system than doing filtering, joining, and paging on every request. applying a filter based on an array of rejected values would definetly add processing time to each request. it wouldn't exactly "bog down" the server, but it would make it work quite a bit harder"

didnt know this. you got me there. But I dont really want this feature added because I would be on half of everybodys block list.

[Edited on January 13, 2002 at 6:28 PM. Reason : ]

1/13/2002 6:08:56 PM

Well, sorry, didn't work.

1/13/2002 6:28:22 PM

I'll be the judge of that.

1/13/2002 6:29:03 PM

Quote :

"Insaneman, why don't you just stft. I've been studying computers and programming/webdesign/misc since I was eight, always ahead of ALL of my teachers and professors. Hell, my asm proffessor in my senior year couldn't even do half the shit I can and he had a college degree. So, before you wanna acuse me of not knowing what I'm talking about, maybe you should consider just how much you know, or don't know"

You been doing this since u were 8? hahahahaha, I started at 7. Ask xienze, I've told him this before. You are better than a few professors, big shit, Thats why they are here instead of in a job.

1/13/2002 6:33:46 PM

once again insaneman, you obviously don't know squat about relational databases.

Quote :

"You are overcomplicating this. You have user numbers that go up to about 4000. No key is needed if the whole thing is loaded into the array in order. array[userNumber]. It doesnt take much system resources to keep 50 of these arrays loaded in server memory for those who are logged in."

what if we had 50000 users (6 kb)? what if some jerkoff came and registered 10,000 user accounts and we just had to delete them all? what about in several years when we have that many accounts anyway? both of these situations would lead to userIDs being up in the tens of thousands if not hundreds of thousands. this would expand your fantasy cookie into well over the amount that we would like to have in the request headers. the idea is to build for the future and for every possible situation. your concept would fail miserably. even if we stored it in server memory, somehow merging the array with the result set in order to filter would be intensive in itself.

Quote :

"minor inconvienience. a character could be put at the beginning of the name column that tells the "join" to add a font color tag that blanks out the text"

huh? i am not even going to bother trying to figure out what the fuck you are talking about but why don't you try telling that to any DBA? nobody programs the joins. they are done inside the DBMS and differently algorithims are used based on the characteristics of the two result sets. the most I can ever to is to give a "hint" on to what type of join would probably be the most efficient.

1/13/2002 6:46:47 PM

1000 users online * 6kb = 6MB really isnt that much memory, especially since this is in the future. All of the memory is directly accessible through a single array index. Speed of getting a single users bit stays constant. Ok so the join will fuck it up. I'm sorry TWW was built with such an inflexible language. You win.

1/13/2002 7:04:13 PM

OK How about another private section for people who like each other on here and are willing to pay more so they dont have to worry about these fucknuts? I mean, the PP was a great idea, especially when we thought you would limit who would be allowed in there, but as far as I know you havent done much limiting, I mean I would rather have the cop (dropout) premium, than some of the users who are, in many respects they are worse, say something wrong and they quote and send to the police or other users...shit aint private no more...

1/13/2002 7:18:23 PM

Quote :

"I dont give a rat's ass about blocking people. I just wanted to make bavander look stupid. but anyways..."

well...you failed...however, you still remain a dumbass in my book I.M.

btw- all this shit is greek to me

1/13/2002 7:19:48 PM

Quote :

"I'm sorry TWW was built with such an inflexible language. You win."

What would you have used?

1/13/2002 7:27:14 PM

I have absolutely no fucking clue what they are talking about. But it's neat to see Jake fight with someone.

1/13/2002 7:35:35 PM

ironmike, you cant say I didnt make bavander look stupid if you DONT UNDERSTAND WHAT WAS SAID.

1/13/2002 7:37:40 PM

what would I have used?

1/13/2002 7:40:26 PM

Both of you looked stupid by busting out those clever self-esteem supporting statements about "I coded when I was 5! Booyah!"

1/13/2002 8:02:13 PM

Oh well, doesn't bother me a bit at all. Thanks for your input though.

1/13/2002 8:11:04 PM

nonlogic, its not a clever self esteem statment. Its a fact, and I wouldnt have brought it up if bavander hadnt implied that he started at a younger age.

1/13/2002 8:24:42 PM

Yeah, well, I punched some keys on my Adam SmartBasic computer when I was 2.

1/13/2002 8:37:20 PM

I was not implying that I started at younger age. I was mearly remarking to you acusing me of not knowing what I'm talking about when I did.

Hey, nonlogic, can you teach me how to do that??

[Edited on January 13, 2002 at 8:56 PM. Reason : ]

1/13/2002 8:55:19 PM

punching keys and making working programs must be comparable skill levels. After all, nonlogic the god of computers says so.

1/13/2002 9:00:05 PM

No. I don't have that computer anymore, but I have the book. Two dollar.

1/13/2002 9:00:48 PM

hahaha insaneman, you're arguing with jake about his own website?

hehe.. you gots ballz kid

1/13/2002 10:45:46 PM

InsaneMan
So are you saying that you would hae written your own RDB or that you would have just used Standard IO into and out of a text file?

1/13/2002 10:53:41 PM

I would have written it from scratch.

1/13/2002 11:49:18 PM

insaneman..... write a database server from scratch.. sounds easy doesn't it?

it probably would be relatively easy for environments with little or no concurrency. but when you have to deal with concurrency, everything becomes exponentially more complicated. terms such as "locking", "transactional", and "thread safe" come into play. you see, creating an environment that reliably serves hundreds concurrently is slighly more complex than creating the single user console apps you are probably used to.

1/14/2002 12:03:00 AM

I didnt say it would be easy. It would be very hard.

1/14/2002 12:12:09 AM

OK soo many people think they can build a server I believe my comment was lost, I will repost it now...

Quote :

"OK How about another private section for people who like each other on here and are willing to pay more so they dont have to worry about these fucknuts? I mean, the PP was a great idea, especially when we thought you would limit who would be allowed in there, but as far as I know you havent done much limiting, I mean I would rather have the cop (dropout) premium, than some of the users who are, in many respects they are worse, say something wrong and they quote and send to the police or other users...shit aint private no more..."

1/14/2002 7:59:47 PM

hehe.. call it "Wolfweb Cliques"

1/14/2002 8:16:06 PM

How about WolfWeb Sticks...as in up their asses.

Jesus people, fucking let it go. Ignore the posts you don't like. Move on, skip it. don't try to write a code to get dumbasses out of your life. It's too short.

1/14/2002 9:25:13 PM

Quote :

"How about WolfWeb Sticks...as in up their asses."

HAHAHAAHA

1/14/2002 9:26:20 PM

I agree with FuhCticious- although I would not have sworn and said it that way. The purpose of a bulletin board, unlike email, is to be able to pick the things you want to read and avoid the things you don't. Unlike email where you can be invaded by Spam that you may want to block, in a bulletin board, you choose what you read. I don't like reading all the swear words, and yes, topics sometimes go astry and sometimes I don't like the topics, but its your bulletin board and your free speech. Read what you want and ignore the rest. Most of all, have fun with it.

1/15/2002 10:29:47 AM

i'm with jake. allowing users to be blocked would be horrible and YES it would lead to chaos and confusion.

like say you see a thread and you see someone being a total ass, however you didnt see the posts by 3 other users instigating the shit because you had them blocked.

1/15/2002 12:22:33 PM