RequestForComments: TLTP

That's OK, it means we're not abusing TLTP for extending TLML, which would be like adding special FTP fields right inside the IP layer... TLTP is all about transporting data safely between a client and a server inside SL, ideally it shouldn't have anything to do about what data is sent. Maybe I'll end up adding the T/X/x field at the start to distinguish between data types being transported ?

Or let's first get it working at last

I'm begining to think that the T/X/x stuff is a really good idea, it would allow for easy extention in the future.

And it could go into URLs as well to specify what kind of data to expect from a given server/page.

OK, I thought a bit about side client scripting. I guess sending out a script from the server to the browser is a big security NO, so we have to go the interpreted language way.
What is acceptable:
- sending TLML to the display
- sending TLTP to the browser
- reading parameters with llGet* functions
- using chat functions

... and that's pretty much everything I can think of With this you can say things to the owner or back to the server, make the owner play an animation, play sounds, change the page (browsing through a collection of textures quickly), etc... with no additional TLTP transfer between the client and server.

Seeing this, I'm thinking that the URL format might need reworking a bit. In fact I'd like to incorporate the RPC inside it, so that the code is run when the display prim is touched, instead of being parsed as page index and sent out by the browser directly.

This way you can make a server with a single page that serves as UI controller for, reusing the example in the linked thread, a remote-controlled vehicle (complete with control buttons and gauges). The display prim would then just contain RPC code that says "forward" or "stop" etc... on a private channel that a seperate script in the vehicle listens for.

It would make it much easier to use TLTP server / client with pretty much anything

[Edit]
Wait, it's possible to use this way already. But I still want to put the RPC code in the URL of the display prims.

The first versions of the TLML scripts had that but i stripped it so the root could decide what method of comm to use but i'll re-add it; this will require a rework of TLML (which i've been wanting to do, you shouldn't be able to run multiple XTM commandsby chaining TLML commands)

Let's just add comm methods for this then ?

I'm thinking of making the parsing of URLs by the browser more robust. Right now it rejects anything that is not a 4-element TightList, or zeroth-channel chat URLs.

It should instead reuse whatever previous server settings were used if absent. This way I can just pass the next page's index and the browser knows to reuse the last server channel, or I just pass a channel and index, etc...

Thinking about it, it should really be more versatile. After all the server name isn't so necessary, even though it's useful for bookmarks and "DNS-like". So I'll just make it an optional last field.
Revised URL format:
Zeroth field: index
First field (optional): comm_method, if not default (chat)
Second (optional, if first field is set) field: channel/key, if not present reuse last one
Third (optional, only if first and second fields are set): server name

Further comm methods might use a different layout, even. Sounds OK ?*

Oh, and let's unify comm methods between URL requests and TLML answers It'll make it easier to combine a client and a server in the same prim (might lead to interesting networked games).

sounds good.

About the passing of notecard keys to the browser ... you can only read a notecard if you have full perms to it.

I have reason to believe (haven't verified) that if you know the key you can read it regardless of permissions.

I'll hammer out some scripts to what i'm thinking. This won't replace what we have already but add to it.

I'm rewriting the browser entirely. I've updated the URL format.

[Edit]
If the server passes a notecard's UUID to the browser, the browser then reads the notecard by itself as TLML ? Let's call this an über-caching of pages

[Edit2]
Still thinking of unifying the comm methods and TLTP special codes... What should the server be authorised to request of the client back, that the client can already receive from the server ?
- fixed text ?
- a notecard's key ?
- any notecard's ?
- inventory (once O2O is fixed) ?

Browser rewritten, hope you like it better

Let's make an exhaustive list of communications between client and server. Then we establish a format for distinguishing between the common and the specific communication types. Bold types already exist in the current specs.

Server can send to client:
- TLTP answer
- UUID/InventoryType pair
- plain text
- URL
- text/channel pair

Client can send to the server:
- TLTP request
- URL
- plain text

What else should the server be able to request from clients ? Inventory ? Should we make it possible for the client to remotely make the server say things on a private channel ? It's all a matter of deciding what is acceptable to remotely pilot... Ideally the server only reacts to standardized signals from the client to avoid any security breach. How can we lock this down yet make it simple to use with almost everything else ?

Also, there is a problem with the current "special TLTP codes", it's that they should be in the lower layer of communication instead of residing inside TLML lines.

I think we should join TLTP request and TLTP answer into simple URL passing, both ways. Plus it only makes sense that if an email-based server can advertise by chat, clients that only accept email should be able to request data, too.

We're hitting v0.3 of TLTP now.

I'm making major changes to the way pages are requested to enable the making of pretty much anything with a standard client and custom server combination.

TLTP "codes" are moved out of TLML and back into TLTP, as per Strife's original suggestion. Now the first character of all transmission describes the type of transmission, followed by necessary information in TightList format (be it a TLML command, an XTM or XTMP command, an anim or sound request, chat request, TLML GET or PSH, URL, XTM or XTMP commands, or RPC command). Here's the breakdown:

The first 4 types replace TLTP-PSH:
T => TLML command
t => TLML-in-this-notecard's-key
x => XTM command
X => XTMP command
U => Get-this-URL (replaces -06 redirections and TLTP-GET)
S => Play-this-sound (replaces -07 code)
A => Play-this-animation (replaces -08 code)
C => Say-this (replaces and extends -05 code)
c => Say-this-to-owner-only
R => RPC command (replaces -09 code, but still not supported, see specs below)
--

I'm thinking of adding parcel media URLs control commands. Thoughts ?

I'm also thinking of allowing servers to send inventory to the browser under owner supervision (using llAllowDrop) so that the browser can act upon the sent object (downloading of bookmarks is an obvious use).

These changes break the server-client scheme a bit, by providing ways for a server to ask a page from browser, or for a browser to tell a server to display something, for example This obviously allows for any kind of remote display.

I'm also adding back server-key-based filtering back on the client, for security purpose. The owner should always be able to decide whether or not to accept content streamed at his/her browser.

I'm making changes to the browser and server scripts, starting now. If anyone is thinking of any additional type of transmission to add to the list above, feel free to post

TLTP-RPC
I'm thinking of making this work with plugin scripts you can add to your browser. They would be called by their name in the same way my Magic Bracelet calls spells: via a link message. The key of this message should contain all necessary parameters taken from the RPC command, and the string should be the name of the plugin script to call. The integer field should be the internal code for RPC, I'm choosing 4400.

This way the Browser and Server can be interfaced with almost anything else easily via link messages or chat commands

[Edit]
As can be seen, v0.3 implies major change to TLML as well. I suggest that the three-digit format be abandoned for a simple integer-cast-as-string format. Negative codes can still be used for errors pertaining to the handling of an URL request.

Strife, can you make the XTM's server/page check work better with the new version ? Or better yet remove server check entirely since it'll be done at the browser level ?

I've just now realised that version 0.3 transforms client and server into remotely-pilotable finite state automatons

... nevermind.

[Edit]
As a side-note, we finally have a way to automagically import (and soon, export) whole objects from text

Wew, the move to 0.3 is done, I updated TLTP and TLML pages, including the sample browser and server codes I'll look into the scripts a bit more to look for possible bugs, then proceed to test it all this weekend (I got me 4 days off).

I'll start hammering away at the new scripts. The server code has to match or you have to nest the XTM command though TLML otherwise you have nasty security issues.

I'm going to be writing a dns server shortly.

We need a name for this entire thing. How about Touch Link Network (TLN)?

TLN ? TLN Service ? Either is ok for me

XTM has to sit in TLML ? So it's not a seperate data type ? Then it needs to be sent in a T(TightList) format with a specific negative code, just like in v0.2...

^^' no
I just haven't built the cache yet for XTM commands so they can be replayed after the config command comes though.

OK, I've moved XTM/XTMP back in TLML (code -10 and -11).

[Edit]
Or maybe I should revert it back ?

o_o its just fine having them have thier own letters
they don't need numbers; matter of fact it would be better if they didn't

thats all i was trying to say ^^'

OK, straightened a few things back I'm still a bit confused about the J data type, though

[edit]
Is it OK to resuse the code -5 for signaling an endpage in a joint notecard ? All it'd need is to nuke the data query when read in the browser script, right ?

Reinstated the -97 wait code, with a settable limit in the browser. Identified all email comm with the subject "TLTP", both ways. Added a field for sound play volume. Fixed compatibility issues with the server code.

[Edit]
Added a sample RPC plugin.

I updated the browser and server to v0.32, they both work correctly (tested in SL 1.7.1(2)).

Added a Reload button to the browser.

Strife, why is the timer event of the browser "omg so wrong" ? I know it's far from perfect (keeping all the server references until it stops getting any for a given time), but I don't see anything really wrong about it (it's not gonna eat the pages or mess the display).

All sounds good to me.

I was actualy going to implement a DNS service, just haven't gotten around to writing it. For the TLML-L notecard sceme it would help not to have to comform to the 4 feilds.

line-number, "2", notecard-key, server, notecard-name

I'm adding a few new letter flags "a", "K", "P", animation-stop, take-controls, request-permissions. a & p are writen but K i'm still bouncing ideas around my head. right now it has a dummy function.

edit: i suppose i could make it
tightlist(line-number,notecard-key,notecard-name), "2", server, dns