The Prototype Offline Application
The offline C# application shown in the screen shot above is complete and working. The top button causes an access to our database on ZenovkaTek.com which will return the desired parameters for our AI plant scripted object. Clicking the second button will similarly access the ZenovkaTek.com database, this time returning the channel ID. The channel ID is requested by the scripted object on Second Life and transmitted to a page on ZenovkaTek.com which posts it in the database. Of course, we could also just type those values into the text boxes. The real story is what happens when the third button, labeled “Transmit” is clicked. The code for the event handler for the “Transmit” button is posted on our website.
The posted code begins by using the RequestMessage class previously described. An instance is created and fed the channel ID, the two parameter values as a comma delineated string, plus a randomly generated integer value. The latter value is only there because the XML format of the message requires there to be a single integer parameter. The resulting XML message, stripped of all newlines and tabs, is returned by the GetMessageString() method of the RequestMessage class.
The code which follows sets values for the HTTP headers, declaring the method to be POST and the mime type to be application/x-www-urlencoded. Finally, the URL of the Linden server which will receive the message, xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi, is used in the argument of the WebRequest.Create() method to create an instance of HttpWebRequest. That will initiate the HTTP request. Once the XML-RPC message is written into the HttpWebRequest object’s request stream, and the request stream is closed, the HTTP request can be initiated.
The HTTP request is initiated by calling the HttpWebRequest object’s GetResponse() method. Note that it is called in a try/catch block. You can see in the catch part of the block that there are clearly a lot of things that could go wrong, and the switch statement is there to see which, if any, of these errors would have caused the problem. The cause of an exception, should one be thrown, would be printed out on the status printout.
The Linden server handled the parsing of the incoming XML, extracting the parameters and sending them to the scripted object. As you will see in our next post, the scripted object simply returns any parameters to the Linden server, and the Linden server will formulate the return XML message and send it to the requesting offline application. Our application will then have to handle the parsing and parameter extraction after the response is received. Currently, the scripted object is simply echoing the values it received. You can see in the status readout in the screen shot of the application that what was sent out was correctly echoed back and received.
The XML parsing uses the so-called LINQ to XML axis methods of the XElement class. The return XML looks exactly like the XML which was sent out, except for the name of the root element. Our application sent an XML message with a root element <methodCall> and the return XML has a root element <methodResponse>. Recall from a previous post that the three values transmitted, hence the three values echoed back are (1) the channel ID; (2) the Growth Rate and Average Life Span values concatenated in a comma delineated string; and (3) an integer value thrown in to fill out the Linden defined XML message. Each are contained within a <member> </member> tag pair. Within that tag pair the message is further partitioned into a name and a value as shown in the message exceprt below:
<member>
<name>Channel</name>
<value><string>6df57cf4-68b7-b958-5b6c-10cb9f2fa391</string></value>
</member>
<member>
<name>StringValue</name>
<value><string>6.35,1.58</string></value>
</member>
<member>
<name>IntValue</name>
<value><int>1413957003</int></value>
</member>
Parsing is additionally complicated by the fact that each member value is further encapsulated in a tag pair which declares the data type of the value. Additionally, our code must separate out the Growth Rate and Average Life Span values which must be returned as a comma delineated string. Once that is done, the result is printed on the status readout as you can see in the screen shot at the beginning of the post.
The LSL script is complete to the extent that it requests a channel ID, receives the parameters passed to it by the Linden server, and correctly echoes them back to our offline application. We have a few more things to do with the script, and the scripted object in which it resides, and will post that information next time.
Our next post will complete the prototype phase of the project, and illustrate the various techniques necessary to use XML-RPC with LSL scripted objects on Second Life. There will still be quite a bit to do with the AI objects, as we will show you in subsequent posts.
Tags: .NET, C#, LINQ, LSL, Second Life
