User:Vagabond Carter
Revision as of 15:00, 15 January 2012 by Vagabond Carter (talk | contribs)
Welcome to my userpage!
<img src="https://my-secondlife.s3.amazonaws.com/users/vagabond.carter/sl_image.png?7a0d3c7e9e612d674d949a06eb9e5aba">
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)|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 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