User:Vagabond Carter

Welcome to my userpage!

Profile image

Host of Stark Reality on Krypton Radio.

LSL coder

CGI artist

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

SLRodent Protocol

A proposed simple Gopher based client /server protocol for use in SL

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)|QUERY: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 accordingly. 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. 

Links included in plaintext

Gopher Specifications [2]

Silverday Object DNS [3]