Difference between revisions of "User:Vagabond Carter"

From Second Life Wiki
Jump to navigation Jump to search
(Created page with "Host of Stark Reality on Krypton Radio. LSL coder CGI artist Resident of Second life since 2007 SL profile : [https://my.secondlife.com/vagabond.carter]")
 
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
Host of Stark Reality on Krypton Radio.
== Welcome to my userpage! ==
LSL coder
 
CGI artist
[[File:VCimage.png|thumb|alt=Profile image|Profile image]]
Resident of Second life since 2007
<li>Host of Stark Reality on Krypton Radio.
<li>LSL coder
<li>CGI artist
<li>Resident of Second Life since 2007


SL profile : [https://my.secondlife.com/vagabond.carter]
SL profile : [https://my.secondlife.com/vagabond.carter]
== SLRodent Protocol ==
A proposed simple Gopher based client /server protocol for use in SL
<pre>
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.
</pre>
Links included in plaintext
<li> Gopher Specifications [http://en.wikipedia.org/wiki/Gopher_%28protocol%29]
<li> Silverday Object DNS [http://www.silverday.net/sqndns/index.php]

Latest revision as of 15:23, 15 January 2012

Welcome to my userpage!

Profile image
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]