User:Vagabond Carter

Welcome to my userpage!

Host of Stark Reality on Krypton Radio.

LSL coder

CGI artist

Resident of Second life since 2007 SL profile : [1]

SLRodent Protocol

SLRodent 

Submitted as a suggestion for HTTP_IN services in the Second Life platform of Linden 

Lab and variations thereof where another protocol is not more practical. This is Not a 

secure protocol, and as such its use should not be for anything non public or 

restricted access. This serves well for small games, information libraries and Roleplay 

systems.

This document and concept heavily draws on Gopher please see 

http://en.wikipedia.org/wiki/Gopher_%28protocol%29
for more information.

Connection:
This to be achieved using more or less normal llHTTPRequests. What is different is the 

way in which replies are sent.

Overview:

Client sends  ==> llHTTPRequest(ServerURL,[HTTP_METHOD,"GET" ], "");
** REQUESTS UNDER THIS PROTOCOL SHALL BE GET METHOD ** 

Server receives request, body is blank so Root menu is sent via llHTTPResponse
Root menu may reside in a notecard in the server, be hard coded, or dynamically 
generated.

body will be /n separated lines in the following format
(code)|(string displayed)|(url)|(body)/n

Thus all 4 fields are |(pipe) separated for easy parsing.

(code) may be one of the following single characters:
I - Information for display, not a command or link. Means of display is up to the 

client.


L - Link, the (url) and (body) will be sent by the client in llHTTPRequest((url),

[HTTP_METHOD,"GET" ], (body)) if this option is chosen by the user. (url)may be the 

Servers own, making this self referencing or that of another server. Link responses may 

be from notecard, hard coded or dynamic just as the main menu is. It is good form, but 

not required, for Link responses to include a link back to the menu that led to them.


E - Execute Command,  the server at (url) should Do Something and respond appropriately 

in its llHTTPResponse body, staying within this protocol even if the response is as 

simple as "I|Command accepted||/n".(body) will be prefaced with "ACTION:" in these 

lines.


S - Send Request, the client must append + "|USER:" + (userkey) in its HTTPRequest 

(body), the server at (url) is expected to send an object or notecard via 

llGiveInventory to (userkey) if authorized by the server to receive it.(body) will be 

prefaced with "SEND:" in these lines.


Q - Query, this is the only menu type that takes an argument, it is functionally 

similar to Execute with the body taking the form of "QUERY:(body):ARGUMENT where the 

string ARGUMENT is provided by the client.

        
Example:
Alice sends Bobs Server an empty GET request.

Bobs Server replies with:
I|Welcome to Bobs server|NULL|NULL
I|Options|NULL|NULL
L|Carols Server|(CarolsUrl)|""
E|Read my guestbook|(bobsUrl)|ACTION:Guestbook
Q|Sign my questbook|(bobsUrl)|ACTION:GuestSign:*  
S|List of people who owe me L$|(bobsUrl)|SEND:owedby

NULL here is a placeholder, indicating these values do not matter and should be ignored 

by the client.
"" indicates an empty string.
* Note as this is a QUERY Item the client will append additional information to the 

(body) here.


How Alice's client displays the lines is up to her client, this could be as simple as 

hovertext, but Alice's client must provide her a means of selecting from the L,E,Q or S 

options. 


Once she has made her choice the client must send the appropriate httpRequest appending 

as needed + "|USER:" + (userkey) to the body in S requests as well as providing 

ARGUMENT in Q Items.


URLs must be direct URLs. Given the unstable nature of HTTPin addresses, use of DNS 

Forwarding such as provided by SilverDay ObjectDNS 

(http://www.silverday.net/sqndns/index.php) and other similar services is advised.


Extensions :
Servers may use additional codes, but clients may simply ignore those lines if they are 

unfamiliar with them. Potential Extension codes might include; B - background texture 

UUID, H - WebPage, and others.


LSL implementation notes:

Request types can be determined by parsing the (body) of the request. A blank body 

should return root menu, probably from a notecard.


L type Requests can easily be served by reading notecards contents into (body) for 

llHTTPResponce, generally these will be named accoringly. e.g., L|Submenu|(url)|

Submenu, would have the server at (url) look for and return the contents of a notecard 

named "Submenu" to the client.


E,and Q type requests can be passed on in the form of link messages to subtasks

(scripts), with some mechanism in place for the subtasks to offer a reply e.g. 

llMessageLinked(LINK_SET,SomeControlInteger,(body),RequestID).

S Requests will simply llGiveInventory, where allowed by permissions. It is advised 

that scripts Not be allowed to be sent this way.