User:Vagabond Carter

From Second Life Wiki
Jump to navigation Jump to search

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

    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 
    This document and concept heavily draws on Gopher please see for more information.
    This to be achieved using more or less normal llHTTPRequests. What is different is the 
    way in which replies are sent.
    Client sends  ==> llHTTPRequest(ServerURL,[HTTP_METHOD,"GET" ], "");
    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 
    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 
    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 
    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.
    Alice sends Bobs Server an empty GET request.
    Bobs Server replies with:
    I|Welcome to Bobs server|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 
    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 
    ( 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. 
    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]