Interesting XML-RPC thoughts.

One: Second Life, as far as I can tell, does not meter incoming XML-RPC requests.

Two: I know for a fact that not only can remote_data and listen run at at the same time, but also listen and timer. As slow witted as this makes me sound, I'm now inclined to think that LSL is a true event-based language (although one nestled in a state-based language). What does this mean?

Three: With a properly timed daemon, running on either my home network or a shell account, I could have an almost real-time connection to an outside computer, if I made sure each exchange were carefully coded -- although, given that the XML-RPC struct has a built-in int value, it almost seems like they were accomodating keeping track of multiple string transmissions. This is very interesting, because...

Four: It means every word the Lindens have said about "needing to regulate the cost of out-going XML-RPC calls" is a lie.

When you say "run at the same time", are you saying that you've seen something like this happening?

remote_data event handler starts
listen event handler starts
listen event handler finishes
remote_data event handler finishes

?

Because if that is true, that pretty much changes everything I'd assumed about how LSL event handlers worked. I would be really surprised if this were true, so I think you mean something else with that statement.

Also, I don't understand the difference between a "state based language" and an "event based language". Of course, theory was never my strong point The event queue is maintained between state changes - is that what you're referring to here?

But it would be much harder for you to maintain that connection to thousands of machines at the same time. Easy peasy to constantly send outgoing packets to thousands of machines if you have outgoing XML-RPC.

More like...

A is set to "hello"
remote_data starts
listen starts
remote_data recieves request, transmits A (hello)
listen changes global the value of A to "goodbye"
remote_data recieves request, transmits A (goodbye)
listen changes the value of A
remote_data ends
listen ends

It's the same "huge loop" you'd see in a Windows GUI program.

Nope, you're wrong.

When you say "listen starts", do you mean that the listener has been activated, or that it's actually received a chat message and is processing it, and in the middle of that the control switches over and starts processing the remote_data request? If you mean the listener is active, then that makes sense. If you mean the listen event got triggered, then I still don't understand this. For instance, are you saying that you can write code like this:

default
{
    listen(integer channel...)
    {
        llSay(0, "Entered listen");
        // Do stuff here
        llSay(0, "Exited listen");
    }

    remote_data(...)
    {
        llSay(0, "Entered remote_data");
        // Do stuff here
        llSay(0, "Exited remote_data");
    }
}

And you'll get:

Entered listen
Entered remote_data
Exited remote_data
Exited listen

?



But even there, you won't start processing a new event until you've completed processing the previous event. Unless you're in a multi-threaded application, and LSL scripts aren't multi-threaded. At least, that's my understanding of how it works.

So you could have a remote_data event, which gets handled, and picks up the current value of A, which is Hello. Then someone says "Goodbye", and the listen event happens, which updates the value of A to Goodbye. Then another remote_data event happens, which again picks up the current value of A, which now happens to be Goodbye.

Try these out. Run the first in a prim, run the second on either your home computer or a shell account. Start the LSL/prim first, place the key it spits out in the Perl code, and start the Perl script. It's not a very exact or useful program, but it proves my point...

LSL Code

// Globals
key gChannel;
integer gListen;
integer gCounter = 0;
string gMsg = "";

default
{
    state_entry()
    {
        llOpenRemoteDataChannel();
        gListen = llListen(0, "", NULL_KEY, "");
    }
    
    listen(integer channel, string name, key id, string message)
    {
        if (message != "")
        {
            gMsg = message;
            ++gCounter;
        }
    }
    
    remote_data(integer type, key channel, key message_id, string sender, integer ival, string sval)
    {
        if (type == REMOTE_DATA_CHANNEL)
        {
            gChannel = channel;
            llSay(0, (string)gChannel);
        }

        else if (type == REMOTE_DATA_REQUEST)
        {
            if (gMsg != "")
            {
                llRemoteDataReply(channel, message_id, gMsg, gCounter);
            }
            
            else
            {
                llRemoteDataReply(channel, message_id, "Ready", gCounter);
            }
            
            if (sval != "")
            {
                llSay(0, sval);
            }
        }        
    }
    
    state_exit()
    {
        llCloseRemoteDataChannel(gChannel);
        llListenRemove(gListen);
    }
}

Perl Code

#!/usr/bin/perl -w

use HTTP::Response;
use LWP::UserAgent;
use strict;
use XML::Simple;

# Second Life variable
my $slXmlGateway = 'http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi';
my @data = <DATA>;
my $slkey = 'KEY-VALUE-GOES-HERE';

my $cmdque = 0;
my $que = "";

while (1)
{
    my $cntr = 0;
    my $xml = &sendweather($slkey, $que);
      
    if ($xml ne '0')
    {
        my $xmls = XMLin("\n" . $xml);
        
        my $struct = $xmls->{params}->{param}->{value}->{struct}->{member};
        $cntr = int($struct->{IntValue}->{value}->{int});
        
        if ($cntr > $cmdque)
        {
            $que = $struct->{StringValue}->{value}->{string};
        }
    }
    else
    {
        
    }

    if ($cntr <= $cmdque)
    {
        $que = "";
    }
    elsif ($cntr > $cmdque)
    {
        $cmdque = $cntr;
        print $cmdque . '> ' . $que . "\n";
    }
    elsif ($cntr == 0)
    {
        $cmdque = 0;
    }
    
    sleep(3);
}

sub sendweather
{
    my ($slkey, $string) = @_;
    my $envelope = '';
    my @temp = @data;
    
    # Loads XML-RPC request into memory
    foreach my $line (@temp)
    {
        if ($line)
        {
            $line =~ s/\$slkey/$slkey/;
            $line =~ s/\$code/100/;
            $line =~ s/\$string/$string/;
            $envelope .= $line;
        }
    }
    
    # Builds the HTTP request
    my $slua = LWP::UserAgent->new();
    my $request = HTTP::Request->new(POST => $slXmlGateway);
    $request->content_type('text/xml; charset=utf-8');
    $request->content($envelope);
    
    # Fires off the HTTP Request
    my $result = $slua->request($request);
    
    if ($result->is_success)
    {
        return $result->content;
    }
    
    else
    {
        return 0;
    }
}


__DATA__
<?xml version="1.0"?>
<methodCall>
    <methodName>llRemoteData</methodName>
    <params>
        <param>
            <value>
                <struct>
                    <member>
                        <name>Channel</name>
                        <value><string>$slkey</string></value>
                    </member>
                    <member>
                        <name>IntValue</name>
                        <value><int>$code</int></value>
                    </member>
                    <member>
                        <name>StringValue</name>
                        <value><string>$string</string></value>
                    </member>
                </struct>
            </value>
        </param>
    </params>
</methodCall>

This kind of thing could, in theory, give you a commandline terminal in-world.

OK, that makes sense, and it's not what I was thinking you were saying Thanks for clarifying that. Yes, listeners and RPC channels can be open simultaneously, and you can receive interleaved events from both inputs. But each individual event is still processed in its entirety before another event is processed. I thought you were saying that that's not true, hence my confusion.

I do something similar with my Piggy Ziggy, which is a pig with an AIML backend so you can talk to it and have a conversation with it. Instead of the server script polling every 3 seconds, I send my script an email from the listen() handler (i.e. when the person my pig is talking to says something). Your method makes sense for a weather update system, but not for mine, because my server script doesn't need to do anything until the person types something into the chat window.