question on llListen() idiom

hi, i was reading some code and wondered what the following idiom accomplished:

state_entry()
    {
        llListen(1,"","","");
    }

this is from the default state of the script that finds resident keys in the w-hat name2key database. it's accompanied in that state by the event:

listen( integer chan, string name, key id, string msg )
    {
        list names = llParseString2List(msg,[" "],[]);
        resident = llDumpList2String(names," ");
        requestid = llHTTPRequest("http://w-hat.com/name2key?name="+llDumpList2String(names,"+"),[HTTP_METHOD,"GET"],"");
    }

and an event:

http_response(key request_id, integer status, list metadata, string body) 
{
        if (request_id == requestid)
        {
            integer i = llSubStringIndex(body,resident);
            if ( i != -1 )
                llSay(0,llGetSubString(body,i,i+llStringLength(resident)+36));
            else
                llSay(0,"No resident named \""+resident+"\" found in the w-hat name2key database");
        } else
            llSay(0,(string)status+" error");
}

As I understand the parameters of llListen(), the parameters are "filters." Leaving the parameters null or blank like that allows the listen() event to respond without filtering by name, key or message. The "1" is filtering by channel, so the listen() event will only respond to messages on channel 1.

http://www.lslwiki.com/lslwiki/wakka.php?wakka=llListen

oh, i dig. so instead of the listen() event looking for stuff from a particular channel, it listens to "everything". alas, that's overwhelming, so there's a gimmick to limit its listening to a filtered set, that provided by the "llListen()" filter.

hmmm.

okay.

thank you very much.

You can have (although it's not regarded as good practise in most circumstances) up to 64 active listeners in a single script.

Listening is a two part thing, like sensors. There is one (or are more) llListen() calls, and one event.

The event is fired whenever an llListen's conditions are met. You must choose a channel, the other parameters (name, key and message) can be left blank (open, respond to anything on that channel) or limit for specific reasons.

The rest are definitely filters, the channel... depends on how you think of filters, but it's different in that it's compulsory, the others are optional.