RequestForComments: TLTP

Greetings again. I have the main engine of a new VM written as well as a decent start at libraries of functions for it. (Working title is 24TH - Second Forth) It is similar in some ways to my previous FORTH engine in that it is another stack based language, however it has full support of floats, strings, integers, vectors, and rotations now. The language has some nifty features, IMHO, such as most of the functions to be able to be performed on an arbitrary amount of arguments. Speedwise, it is probably at least twice as fast as FORTH. It has an embedded command also to execute a TLML string.

I request that an error code be reserved for a server to feed commands to the VM. As far as pre-determining what the VM should and should not be able to do, I think there is no real reason to control it too much, since any abuse that could be performed with the VM could just as easily be performed with LSL (a modified client for example to flood a server).

I will start on a basic DNS setup to map pseudo names to a server key or external server's email. I propose that a pseudo name will begin with a $, which cannot occur (I belive) as the starting character for an email address and of course not a key. Thus the start of a TLTP command would be 000/!1!$myserver!next page. I will set up a root DNS at a static email address (probably [email]dns@secondnetworks.net[/email]) which should be called by the client once (subject: DNS_MAST). The root DNS will return a key to the true repository (RET_MAST:[email]). The client then will send all future requests to this email. Likewise the client should cache some entries (memory allowable amount) to decrease strain on the DNS servers. The DNS servers (whether in world objects or external server) should be sent a request as subject DNS_REQ:[pseudo-name] and will return RET_DNS:[pseudo-name]:[addresss]. The client then will be responsible for replacing future calls to the pseudo-name with the proper address. A return to a DNS_REQ of RET_UNK:[pseudo-name] will indicate an unknown name. Optionally (and what is your opinion??) the DNS could query the servers on a certain set frequency to determine if the server is "alive", and if a mapped pseudo-name's server is not replying, future requests could be returned RET_ERR:[pseudo-name]. I propose as far as pseudo-name authority, an AV's name will automatically be reserved to the individual, as well as any extensions to the name (i.e. AlondriaLeFay.music). I am not sure how to handle other names - some sort of SL-ICANN?

Thoughts?

I'd rather we have a distributed system for associating a server's name with its key. Also, since it's inevitable that multiple name repositories will coexist, it might be wiser to devise a naming scheme that uses the owner's (or group's) name to avoid collisions.

[Edit]
For these reasons I think it's better not to force a particular system over any other at the moment.

There will have to be a starting point for it to be a unified network. There is no reason the DNS server can't redirect the request to a personal level server, based upon root name (i.e. request is sent for JesradSeraph.Pictures to the main DNS. That DNS shoots the request to a JesradSeraph DNS server to resolve the latter part and return the address to the client. Now I can understand the possible fear behind having a single person control the initial "root" DNS. A simple solution to that is allow the actual end user specify the root DNS to utilize, thus if the root provider does something scandalous and roots everything to their server, alternatives can be made. Basically what I am proposing is for the methodology to route things, not necessarily trying to lock it under my control.

Actually, that's what I meant by "based on the name of the owner" Let's say each browser/server maker has its own "DNS" (let's give it a name... what about Distributed Name-Key Association Service - DNKAS, as in "Dinkas" ? It could be extended to support anything's key/name retrieval, like an agent's key from its name, bringing llName2Key to SL at last ?): Strife's DNKA server would redirect any request for "JesradSeraph.bestiary" to my own DNKA service, right ? This method still requires a way for each "root" to know where the other roots are. That's where I want a distributed method instead of a central master service.

I read the XTM and TLML scripts a few times, but I still don't understand exactly how it works in the details

Server sends TLML commands with formatting bit 22 set to prepare some display prims for receiving text, then how does it actually sends the text to display ? Does the XTM command is just sent over with TLTP code -10, and the browser broadcasts it to the display with link message code 3000 ? Or 3100 ? Or 3200 ?

[Edit]
I'm reading the detailed XyText instructions... OK, so we can have one prim display up to 6 characters with a single TLML command sent specifically to it (the easy way), or we can display more by setting up "cells" Lemme read some more.

[Edit2]
OK, got it, the code 3100 is used when using XTMP commands, 3000 for simple config is used by the display script directly, and the two others are used internally by XTM.

I updated my browser (fixed the history bug, added support for multiple TLML in email) and email server scripts (support for multiple TLML in email). I'll update the servers some more to support all the new TLTP codes.

I just realised I had left a discrepancy between the URL format on the TLTP wiki page, and actual implementation in my scripts

The correct format is a TightList composed of 4 substrings, not 3. First is comm method, second channel or key for comm, third is the server's name and fourth is the page index.

The server name is used in bookmarks and history in browser scripts and will certainly have an important role for finding a server in the near future.

Sorry about that

^^' could you update the scripts on the page if they are ready.

There are two XTM link_message channels of importance.

3000 is for sending text to a preconfigured set of prims
3100 is for reconfiguring a set of preconfigured prims (and you can send text too).

I've just gotten around to reading the client code, it looks good.

The client needs to be patched so it sends the current pages url as the key for the link message for XTM commands. For TLML commands it needs to send a config feild which is a tight list containing [source_url, config_root_local_rot, config_mask]

bit 0 of config_mask is the scale of the browser (a float), don't use this.

code -11 is for no config use (3000)

How to use XTM:

000//0x400000/0x0006A/0/0
001//0x400000/0x0006A/0/1
002//0x400000/0x0006A/0/2
002//0x400000/0x0006A/0/3
-11/0/XyTextMod Version 0.20

right now what needs to be done is get the client working in sync with XTM and debug XTM (i'm 99% sure XTM works without any bugs in it).

Also local URL handling needs to be expanded.

I just updated the browser in version 0.26 following your recommendations

Here's what it does right now:

Listen on -9
- when it hears an url, it adds it to the "accessible" servers, SetTexts it and changes color

Touch brings up a menu
- can go to a bookmarked URL
- can go to a listened URL (accessible server)
- can go back to up to 8 previous URLs
- can toggle on/off
- can toggle follows/stays

Going to a given URL
- check the comm method (email or chat)
- send an email requesting the page (if email)
- open an additional random listener and say the page and channel (if chat)

Listen on random channel
- treat the TLML line

Email received
- unpack multiple TLML lines
- treat each TLML line

Treating a TLML line
- check the TLTP code, transmit the TLML to the appropriate child prim* if code >= 0
- treat other codes as required**

Receiving a link message
- checks if it's an URL to go to, treats it if positive

* using: llMessageLinked(target + child_link, 1000, the_tlml_content, (key)TightListDump([current_url, llGetRot(), 0], "&");
Is this correct ?

** XTM is transmitted with: llMessageLinked(LINK_SET, 3000, the_xtm_content, (key)cur_url);
Correct ?

OK (sorry for the GetRot, was still thinking in terms of unattached browser You may want to mod the script a bit about the SensorRepeat), I've updated it again.

The URL format I use is the one defined on the TLTP page... it's a TightList of [comm_method, key/channel, server_name, page_index]
I think it makes more sense to keep it consistent, can you modify the display element to read it, or does it absolutely need the KEY of the server ? I must mention the browser already reuses the currrent server's key if it's absent from the URL passed to it from the display prims.

XTM doesn't care about the method, neither does TLML, it's up to the browser to decide the proper method to use. XTM needs to do security checks so that one page can't hijack another without permission. So it has to be done by key/dns.

The url format that needs to be passed to XTM in the key parramater should be tightlist([key/dns, page_name]) this way it doesn't matter what the method is.

OK, browser now passes (key)TightListDump([server, llList2String(TightListParse(cur_url), 3)], "*" as the key of link messages sent to XTM.

The key variable "server" gets updated whenever listen and email events trigger.

I've updated the email event in the browser, should run faster and use less memory.

I'm writing a simple TLML formatter, it gives out the complete TLML command for reproducing the child prim it is placed in when touched. I'll make it so it strips whatever TLML is set as the prim's description from the result (so it only keeps the differences).

Was just about to update TLTP to 0.24 (which should *crosses fingers* make XTM work without me having to debug)

Do you have sample TLML pages I could use for testing ? (Feel free to update TLTP if needed, although it's up to version 0.25 already)

I total forgot to update the TLTP->XTM bridge.

I've put everything up now. I've done some mods to the browser.

-5/-----------------------------------------------------------
000//0x460000/<1,0.3333333,0>/<.5,.5,.5>/0x0006A/0/0
-98/001//0x400000/0x0006A/0/1
-98/002//0x400000/0x0006A/0/2
-98/003//0x400000/0x0006A/0/3
-970.5
-10/0/XyTextMod Version 0.20

EDIT:
I've been testing it but haven't tested the updated bridge, i don't know if it's working properly. I moved TLML Display Element to version .30 when i got the key format corrected.

I'm using this script in the child to snoop in on link messages

default
{
    link_message(integer a, integer b, string c, key d)
    {
        llOwnerSay(llList2CSV([a,b,c,d]));
    }
}

EDIT2:

change error code 12 to 97

What are you using the -98 TLTP code for ? I don't see anything done with it in the browser code, it doesn't even triggers the error message Is the -12 code for scaling the browser ? I need to know to update the TLTP page...

-97 is a client side sleep. it is a hack solution. The problem was the events were coming out of order. The XML config link messages from the TLML parser were coming after the XML link messages.

-98 is a comment it does nothing

^^' i forgot to add them to exchangeTLTP but i've done that now

Oh, OK
I thought the protocol was resistant to out-of-order transmission maybe XTM could include an order field and cache the commands until all are received, à la fragmented-TCP.

We would have to do something creative to get out of order transmitions working nicely. But i did come up with a stop gap solution that leaves me wondering about how i've built XTM.

That said i've come up with a solution that solves the problem
You will need fresh copies of TLML scripts off the wiki for this...
Oh and XTM works, this test script works.

000//0x460000/<.5,.166,0>/<-.75,.1,.1>/106//
001//0x460000/<.5,.166,0>/<-.25,.1,.1>/106//1
002//0x460000/<.5,.166,0>/<.25,.1,.1>/106//2
003//0x460000/<.5,.166,0>/<.75,.1,.1>/12394//3/*XyTextMod Version 0.36*

FYI: I've updated the XTM bit mask

Thoughs:

Since we keep version numbers of the scripts i was thinking that when we edit our scripts we increment the version counter, but when we edit the other persons scripts we increment (or append) a letter counter at the end of the name, so it's easy to see which scripts have been updated.

Agreed (although I have not edited yours so far)
So now the XTM config lines piggyback the TLML commands ? If I want to change the text on the display I just send another TLML that contains XTM for the new text, to one of the specially set up prim, that then broadcasts it to the child prims, right ?

You could i suppose, but you can still send regular XTM commands like before. The reason for doing it this way was to avoid the config issue. Doing it this way means that the XTM command comes in after the prims are already configured; solving the timing issue.

^^' and your right i ended up scripting what i didn't want to script.