Coming Attraction: "Kill Files" (Ignore and more)

[John Robinson]

Many familar with USENET News may have heard of the killfile, or of killfiling someone. A killfile is simply a list of names you wish to ignore. Any posts with a matching name in the killfile are discarded, unread.

The Focus software will have the ability to killfile posters, or in other words, the often requested "Ignore" feature.

However, Focus killfiles will be much more.

First, a little info about how the posting software works. When a post is made, a number of records are placed onto a list. This list is the source data for the Self-Search routine among other things. Each record is associated with a comment, but a comment can have any number of such records. The record associates a user with a comment, and also notes how the association is made. This association field is similar to what you might see in a mail program. There are 'From' and 'To' associations, as well as 'CC' and 'BCC' associations. Each mean something different, but all associate a user with a comment.

FROM - The user who posted the comment.

TO - A user mentioned in the "To:" field.

CC - This will be reserved for bumps. It's currently not used.

BCC - This will be used for concealed bumps. Have a long bump list? Use BCC and conserve screen real estate!

The Focus version of the killfile will operate on these associations. This is the "What". You will be able to ignore all bumps (CCs) 'in some particular context'.

The "Context" is the magic, it defines when you ignore "What".

Want to ignore bumps? "What" = "bumps", "Context" = "all".

Want to ignore all posts involving you on a particular thread? "What" = anything, "Context" = some thread.

Want to ignore all posts from some user? "What" = anything, "Context" = some user

Or just their bumps? "What" = "bumps", "Context" = some user.

BUT WAIT, THERE'S MORE ...

Not only will you be able to describe what you want to ignore, you will also be able to describe other actions as well. An "Action" is one of: Ignore, Deny, Allow, or Promote.

IGNORE -- silently discard the comment from your self-search

DENY -- informs the user that you do not wish to receive such-and-such.

ALLOW -- accepts the comment into your self-search.

PROMOTE -- accepts and flags the comment. Want special notice of anything JohnRob bumps to you? "What" = "Bump"; "Context" = "user John Robinson"; "Action" = "Promote"

You can specifically "ALLOW" comments because you can set defaults. You can setup your defaults to never allow bumps from anyone. And then further instruct the software to allow bumps from JohnRob. The more specific defined rule wins.

Now, I should note that IGNORED or DENIED comments are still accessible. It will take an extra click to get to these, but that will not be a problem because you didn't want to see them in the first place.

Additionally, you will be able to delete individual comments from your Self-Search, or even wipe the slate completely.

These features are not yet ready, I have some footwork to do before I go there, but this is what is in store for you.

Of related interest, we will have the ability to WATCH various things. A separate list will allow us to know, via automatic BCC bump, any new thread posted to your favorite forum. The watch list is further out yet, but will be a reality as time permits.

[RnMomof7]

Wow I do not know how I feel about that..could be no one will want to talk to me John..I just read on another forum that FR is not allowing graphics anymore is that true?

[John Robinson]

I may also have a DISSUADE action, which is similar to DENY but gives the user an option to do it anyway. It will say, in effect, something similar to "I do not like receiving bumps, this better be good."

[John Robinson]

Not allowing graphics? Not true!

[RnMomof7]

Thanks...I didn't think so

Nice of you to talk to me:>)

[John Robinson]

*AHEM* The ignore feature will also need to IGNORE comments in-thread and Freepmail too. That will be handled similarly.

[smith288]

How totally funked up does your table design look?

[Ernest_at_the_Beach]

Oh my , there was a thread just last night where a Freeper was asking how he could do something that was very similar to what you seem to be describing.

We gave him a hard time!

[Ernest_at_the_Beach]

ping!

[Atlas Sneezed]

Does this mean that I will be able to ignore my own posts in my self-search list, so that I see only the responses, and not my own posts?

[Ernest_at_the_Beach]

ping!

[Ernest_at_the_Beach]

Does this mean that I will be able to ignore my own posts in my self-search list, so that I see only the responses, and not my own posts?

That would be excellent. If one posts an article that gets a lot of response you lose sight of pings that you would like to see!

A lot of time is wasted just trying to find replys to you that you have not responded to!

[John Robinson]

Not bad, really.

There is a comment table, a comment_user table with the comment-to-user associations, and a killfile table.

create table killfile (
    kf_rule_id int unsigned not null auto_increment primary key,
    kf_owner_uid mediumint unsigned not null,
    kf_action enum('ignore', 'deny', 'dissuade', 'allow', 'promote') not null,
    kf_what enum('all', 'from', 'to', 'replied', 'cc', bcc') not null,
    kf_context enum('user', 'forum', 'thread', 'comment') not null,
    kf_context_id int unsigned not null,

    index owner (kf_owner_uid, kf_context, kf_context_id)
);

When a post is made, and the program is writing the comment-to-user table, it will consult the kf_rule table where kf_owner_uid = the target user, and kf_context will be, in turn, the current thread, the current forum, the current user, etc.

Mind you none of this lives as real code just yet. It's still on my scratch book for the most part.

[Ernest_at_the_Beach]

That is perl code?

[John Robinson]

kf_context also has an 'all' in that enum. And the value of kf_action, if found, is used to adjust the fate of a marker on the comment_user table. Regardless of what is in the killfile, a record will be written to comment_user-- that table is used for much more than self-search. The marker field will, however, be included in the self-search indexes.

[John Robinson]

SQL. MySQL to be exact.

[John Robinson]

Perl code looks more like:

sub get_reply {
    my $reply = {};

    $reply->{text} = $Focus::r->cgi->param('reply');
    if ($reply->{text} =~ m#<\w+(?:.|\n)*>#i) {  # MAGIC
        $reply->{text} = html_filter($reply->{text});
    }
    else {
        $reply->{text} = html_format($reply->{text});
    }

    my $l = new Focus::UserLookup;

    $l->lookup($Focus::r->cgi->param('name'));

    $reply->{rcpt_string} = $l->lookup_string;
    $reply->{rcpt_list}   = $l->lookup_list;

    if ($reply->{text} !~ /\S/) {
        push @{$reply->{errors}}, "Enter a reply.";
    }

    push @{$reply->{errors}}, map { $_->{text} } $l->errors if $l->errors;

    $reply;
}

Scared ya, didn't I?

[John Robinson]

Oops. kf_rule table == killfile in the example.

[Ernest_at_the_Beach]

Yes, you done good there.

Doesn't look like COBOL or FORTRAN!

[smith288]

Im the kind of guy who will just make it with access and tinker until it is the way i want it. Is that your type of scratch pad or is it physical paper?