RequestForComments: TLTP

I'm thinking of making TLTP-over-email stateless and connectionless, to simplify processing on both sides. This way it could scale up much better and wouldn't require the server to keep track of each connection (no more timeout management, mainly, and saving on the 3 connection and disconnection emails). Thoughts ?

What about extending this to the chat transport method ? I need a simple method for allowing one object to speak to another on a channel only the two of them know, without having one "connect" at all... If I could avoid the first ACK email entirely, that would make the server really simpler to make and improve performance a great deal

[Edit]
Using a combination of the server's and client's keys would give a channel number without communication, but it would not be secret. Aww, LL, can't we simply have an llKeySay like we have llOwnerSay ? AFAIK Avatars can chat in private (the Talk to... feature).

I think there are fun things that can be done with this and current media streaming capabilities

[edit]
Thinking more about connectionless communication. Even if there is a method for the client to find out what channel the server is waiting for requests on, as long as it is transmitted on chat the pages can be sniffed out anyway. So the whole "make it secret" point is moot. That's why I thought about dropping TLTP-over-chat entirely for a moment. But then the performance advantage as well as geographical autodiscovery (wow, big words here ) change the deal.

The transmission could be encoded in some way to make sure only the client can decode it. Is it worth the cost and complexity ? I'm not sure. Let's say only public info should be published by chat-servers, and have the server announce itself on -9 instead of clients. And everytime someone connects, open a new listener and advertise this one instead (let's make sure the client closes its -9 listener and opens its communication listener BEFORE requesting the default "home" page). And if two clients try to connect simultaneously, the first one gets the cookie, the second one goes back to waiting for the next -9 announcement (which should arrive quickly).

OK, making it entirely connectionless in its 0.2 version, for Great Justice

[addition]
The -04 error code should also provide the index of the default page. This way if client and server support different default names they can still communicate.
OMG I forgot the Redirect error code ! It'll be -06.

[Further thoughts]
There's still some connection management on the server in chat mode: it's gotta close those stray listeners after the client moves away. Hmmm, at least I tried. Unless the pages can be filtered by some other method on the Server->Client way, using multiple chanels requires it.

It also means the server controls the range of communication instead of the client. I hope this does not lead to abuse of llShout...

[Edit]
Got the solution Just like with HTTP, the client reconnects for each page ! Heres how it works:
Server advertises its default URL on -9
Client requests a page on -9 and specifies which channel to send the data back to
Server sends the page on the channel given in the client request.

I'm still wondering if I should add a way to request a specific prim of a page. It's easier than ever to elegantly make now, except for the TLTP-GET part.

[Edit]
Strife, what about reserving a bit of the format to specify "standard XyText shape" ? This could save a LOT of bandwidth when making extensive use of XyText display prims.

Yes rotating the prims for XyText is an issue. I'm still trying to figure out how best to do that. The trouble is the rotation of the root, suppose i could pass that as part of the config.

Ok so two bits for XyText
Bit 6 default rotation for xytext (that is horizontal and facing the user).
Bit 22 setup xytext (characters [3,6], CellChannel, TightList(Info_Mask,Info_Attributes))

Info_Mask
Bit 1 CellCharPosition
Bit 2 CellUseFading
Bit 3 CellHoldDelay
Bit 4 CellFont

I've solved the problem of remaps be eliminating the need for them.
I've writen a function that replaces XyText escape codes with the characters that are supposed to be sent (and supports a few new escape codes).

Before the function can be used the cooked string needs to be decoded. when scanning for XyText Escape codes it is uses raw to identify the code then replaces it with the corresponding cooked character.

string cooked;
string raw;

string Unescape(string a, integer m)
{
    string  b = a;
    integer c = -1;
    integer d;
    integer e;
    string g;
    while(d = llSubStringIndex(b, "\\") + 1)
    {
        g = llGetSubString(b,d,d);
        c += d;
        
        if(g == "\\")
            a = llDeleteSubString(a,c,c);
        else if(g == "e")
        {
            e = llSubStringIndex(raw,llGetSubString(b,d+1,d+1));
            if(e + 1 && e < m)
                a = llInsertString(llDeleteSubString(a,c,c + 3),c,
                        llGetSubString(cooked,e,e));
        }
        else if(g == "u")// \uXXXX
            a = llInsertString(llDeleteSubString(a, c,c + 5),c,
                    UnicodeIntegerToUTF8((integer)("0x"+llGetSubString(b,d+1,d+4))));
        else if(g == "U")// \UXXXXXXXX
            a = llInsertString(llDeleteSubString(a, c,c + 9),c,
                    UnicodeIntegerToUTF8((integer)("0x"+llGetSubString(b,d+1,d+8))));
        else if(g == "r")
            a = llInsertString(llDeleteSubString(a,c, c + 3),c,
                    llUnescapeURL("%"+llGetSubString(b,d+1,d+2)));
        b = llDeleteSubString(a,0,c);
    }
    return a;
}

string byte2hex(integer x)
{
    string hexc="0123456789ABCDEF";
    integer x0  = (x & 0xF);
    return llGetSubString(hexc, x0 = ((x >> 4) & 0xF), x0) + llGetSubString(hexc, x0, x0);
}

string UnicodeIntegerToUTF8(integer a)
{
    if(a <= 0) return "";
    integer b = 0;
    integer c = 0;
    string d;
    if (a >= 0x4000000)
        c = 5;
    else if (a >= 0x200000)
        c = 4;
    else if (a >= 0x10000)
        c = 3;
    else if (a >= 0x800)
        c = 2;
    else if (a >= 0x80)
        c = 1;
    while(b < c)
        d = "%" + byte2hex((((a >> (6 * b++)) | 0x80) & 0xBF)) + d;
    d = "%" + byte2hex((a >> (6 * c)) | ((0x3F80 >> c) * (0 != c))) + d;
    return llUnescapeURL(d);
}

init()
{
    cooked = Unescape("\\u03c0\\u03b8\\u00d7\\u00B0\\u221A" + "\\u00B2\\u00B3\\u00BC\\u00BD\\u00BE" + "\\u00A7\\u00A9\\u2022\u2026"); //You must run this before you can use \e
    raw = "123456789abcdef";
}

default
{
    state_entry()
    {
        init(); // Must becalled before \e works
        llOwnerSay(Unescape("c\\u221A\\r21a\\r21b\\r21c", 16));
    }
}

Brilliant This should be ported back in XyText.

BTW, I suppose the bit 6 for the XyText default shape is not local rotation, but really the "squeezed pyramid" tortured cube shape ? The local Rotation I can send anyway (it'll certainly vary a great deal from page to page).
Yummy, writing arbitrary, script-generated text on curved surface in your browser

You should know that PRIM_TYPE doesn't work on attachments (i should add it to the protocall anyway...).

XyText is being merged into the elements; running it as a seperate script complicates things too much.

The Major change in XyText 1.1.1 is

ResetCharIndex() {
    gCharIndex  = " !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`"
                + "abcdefghijklmnopqrstuvwxyz{|}~"
                + llUnescapeURL("%CF%80%CE%B8%C3%97%C2%B0%E2%88%9A");
}

Awww, can't tell a cube to set up as expected... This means we'll have to build the prim pages with cubes that have the negative Z axis towards the reader, when they show only one texture, and make all the display prims in browsers to be flat, 0.33 TopYScale cubes ?

[Edit]
I'm making a v1.6 compatible browser anyway, it'll be a small sphere following the owner around that changes color to signal local servers, and hides its display prims inside itself.

Just wondering... think we should concatenate multiple TLML commands ? Notecard lines are limited to 255 characters, and emails to about 800 (useable). That would require some testing I think, but in the meantime, what method should we use for pasting them together ? Yet another TightList ?

Unfortunately, while my Forth engine is probably the most advanced inworld VM, it is lacking any real comprehension of a float (it uses scaled integers to simulate floats since I could not figure out an efficient way for the engine to recognize a float) and fairly poor handling of strings (it was pretty much a hack job, although it probably could be improved upon).

I have been playing with the idea of attempting again to make a VM since my Forth interpretor really did not hit the mark of what I wanted to achieve (a semi-efficient way to update object's functionality regardless of local in world and regardless of point of orgin - i.e. in world server object of external server feeding commands). With that in mind, what functionality would you require? What also could be neat is if the VM code could be broadcasted via TLTP - basically adding a Java'ish layer to TLTP and thus allowing the client to be able to process/interact with less reliance on the server.

Well, for a start, TLTP is relatively extensible: feel free to suggest extensions of the "error" codes. You could for example have a TLML line start with -09 with a line of code appended, and the browser, if it supports it, can then interpret the line

Now the hard part is to figure out what the interpreted language (let's call it YAMeL) should and should not be able to do... and whether it can already be done with plain TLML

[Edit]
It's truly a shame attachments can't use PRIM_TYPE in llSetPrimitiveParams Otherwise we'd be running around with browsers that can replicate entire objects on our screen (think about the shopping possibilities).

I'm thinking of adding a TLTP code for redirecting to an HTTP URL with a call to llLoadURL(). Reactions ?

[Edit]
And while we're at it:
- another code for playing a given sound's key
- yet another one for playing a given animation's key

Two words: llSetText. Support.

Please Strife ?


I can think of a few things, like having the client-side script call a given url every N seconds.

llSetText: no prob but hud attachments don't support it. I'll also add PRIM_TYPE in as well, no point in restricting this to just attached viewers.

You can catonate commands or you can just send multiple commands. Doesn't matter.

Concatenated commands for different display prims are seperated how ? With "\n" ?

I'm surprised that you say attachments don't support llSetText, is that only child prims ? 'Cause I have seen many titlers.

^^' i ment hud attachments i edited it when i saw my mistake (a min before you posted i might add).

Say you want to set different textures on two faces of a prim you could do that by...

000\\0x300\1\66864f3c-e095-d9c8-058d-d6575e6ed1b8
000\\0x300\2\89556747-24cb-43ed-920b-47caed15465f
OR
000\\0x300\1\66864f3c-e095-d9c8-058d-d6575e6ed1b8\0x300\2\89556747-24cb-43ed-920b-47caed15465f

I've come to relize i have no idea how to differentiate between TLML and XTM commands.

How about a single letter prefix on each command
T for TLML
x for simple XTM
X for complex XTM

T000\\0x300\1\66864f3c-e095-d9c8-058d-d6575e6ed1b8
x\0\I like Monkeys
X\0\0x10000\I like Monkeys too

It's better to keep it as extension of TLML, really (since it is ). So instead of adding two characters per command just for distinguishing that, let's have one bit of the format tell if the other bits are XTM or TLML. The parsing code would then just branch between the two cases, no ?

I suppose you could chain them to a specific prim but that makes the comms complicated. Then it would have to be routed though the base prim of the text. Also for a page to modify text in another page it would need a dummy prim to route the updates though.

How i was thinking it would work when Stream A writes XTM into prims of Stream B
                                  _________________
                                 |Prim             |
[Stream B] -----> [parser]-------+->[XTM Handler]  |
                            XTM  |     ^    ^      |
                                 |     |    |      |
[Stream A] -----> [parser]-------+-----'    |      |
            Raw       \     XTM  |          |      |
                       \         |          |      |
                        `--------+->[TLML Handler] |
                            TLML |_________________|


Your suggesting
                                  _________________
                                 |Prim             |
                                 |  [XTM Handler]<-+---.
                                 |        ^        |   |    _________________
                                 |        |        |   |   |Prim             |
[Stream A] -----> [parser]-------+->[TLML Handler]-+---^---+->[XTM Handler]  |
            Raw            TLML  |_________________|  XTM  |        ^        |
                                                           |        |        |
[Stream B] -----> [parser]---------------------------------+->[TLML Handler] |
            Raw                              TLML          |_________________|

duhhh why didn't i think of it before. we don't need a leading character for prim commands.

000\\0x300\1\66864f3c-e095-d9c8-058d-d6575e6ed1b8
x\0\I like Monkeys
X\0\0x10000\I like Monkeys too

with XTM commands they are sent to all prims. While TLML commands are sent only to the prim they are intended for.

parser(string a, string source)
{
	integer b;
	integer c;
	string config = TightListDump([source, 2, llGetLocalRot()], "|");
	string d;
	do
	{
		b = llSubStringIndex(a,"\n");
		d = llGetSubString(a,0,0);
		if(d == "x" || d == "X")
			llMessageLinked(LINK_SET, 3000 + (d == "X") * 100, llDeleteSubString(llGetSubString(a,0,b - 1),0,0), source);
		else
		{
			c = (integer)llGetSubString(a,1,3);
			if(c > 0 && c < 256)
				llMessageLinked(c, 1000, llDeleteSubString(llGetSubString(a,0,b - 1),0,3), config);
		}
		a = llDeleteSubString(a,0,b);
	}
	while(1 + b);
}

OK, you got me totally confused here

I don't know how XyText works at all... but apparently if you need the command sent to all prims then it's best to pass a specific TLTP "error" code, just like how a -99 clear the prim-page. Choose any negative value from -08 to -98.

[Edit]
We must also keep in mind that people will have to make notecards containing those lines of complex code I don't really know how one can extract the configuration data from a XyText prim... so if there's any way to simply use TLML commands to "prepare" prims to receive XyText, then just send the whole text in one XTM line, it's easier to do and I like it.

[Further edit]
I'm adding more codes, so grab one for XTM and another for XTMP while they last Codes so far:
-01 server unavailable
-02 server error
-03 access denied
-04 page not found (append the default page index)
-05 custom error (append something that is then said to the browser's user)
-06 redirect (append an URL)
-07 play sound (append key of the sound)
-08 play animation (append key of the animation)
-09 RPC (append an RPC request -- this will allow to run local scripts, more about this later)
-99 clear the browser's page (useful as first line of the default page)

I'm thinking of getting rid of most of them and incorporating them into the "TLTP-RPC" part. This would allow browsers to support interesting things...

Thats exacty what i'm doing. You initialize each prim then you pass the string all at once. (though you can pass it bits of strings to set default text)

I don't think i'll need any flags. Though if you want to allocate some for XTMP thats cool with me.

Hurray, I got it right finally I'll add the -10 code for this right now.

Hurray, I got it right finally I'll add the -10 and -11 codes for this right now.

I posted a browser script. I'd like to modify it to work with your display element scripts, so I'd like to know:
- What link message codes are used to distinguish XTM and XTMP ? Any other code (apart from the email code) ?
- Right now I send the code 8999 to clear a given prim, should I keep it that way or use a fixed TLML command instead ?

I'll add a TLML command for clearing.