LSL Protocol/Restrained Love Open Relay Group/Prefix

Prefix Discussion

The current relay specification calls for two prefixes ! for meta-commands and @ for commands to be passed through to and executed by the viewer. For the most part, meta-commands are informational only (!release being an obvious exception). x-tensions fall into two significant categories: those that are largely informational and those that could be (but are not) implemented in the viewer. There is no hard and fast line between these two, for example, the currently proposed !gender add-on to the existing relay spec implies functionality that could, potentially, be implemented in the viewer or could be implemented by a script in the relay.

Clearly, though, there is need of some form of prefix for x-tensions, if only to separate them from the functionality required by all relays. There are a number of obvious alternatives: use the existing prefixes and simply document the x-tensions; create a single, new prefix for all x-tensions; and use multiple, new prefixes for the x-tensions. The first choice seems inappropriate, and choices for the second and third are to either use !x- alone or !x- for informational and # for viewer commands.

Clearly, making this choice needs to be done very early in the life of ORG.

Well, I wouldn't draw the line between informational or not, but between RLVR protocol load (commands proper) and RLVR protocol control (meta-commands).

• For me a meta-command is something which is only there for making the protocol work. Information about protocol and relay version (!version and !implversion), are of course meta-commands. But !ping/!pong isn't really informational, neither it is a command that will have a direct observable effect, but it is needed for the protocol to work when you log on. !who gives information, but not about the relay or its wearer, but about the furniture user. !handover makes the protocol able to transfer a session from one furniture to another. !release ends a protocol session.
• Commands proper have no effect on how the protocol behaves but instead have extra-protocol effects (up to now, the only type of effect was issuing RLV commands to the viewer). !vision (or now !x-vision) is also such a command, as it doesn't change anything to the RLVR session, but produces a HUD behavior.

NB: this distinction only makes sense with respect to one precise protocol. Indeed the load of the RLVR protocol contains RLV commands which in turn can have different roles with respect to RLV API (a different "protocol" it encapsulates). For instance @version is load with respect to RLVR protocol, but is clearly a "meta-command" w.r.t. RLV API.

Drawing the line between load and control isn't always easier than between mostly "informational" or not, but I find this distinction more useful. --Satomi Ahn 20:35, 25 April 2009 (UTC)

Hmmmm... you're almost certainly right... !x-vision could be implemented in the viewer, indeed, I wish it was because then I could do without every device trying to put a prim on my screen so it can block this, or that! I think that !handover is in a gray area.. and could be in either camp. It affects the protocol (which device the relay should respond to) but also the RLV API (which restrictions the person is under).

My bottom line is that I would like to get something simple, I really like the !x- convention, but am willing to go with another choice if that makes sense. --Chloe1982 Constantine 13:39, 11 June 2009 (UTC)

Let us wait for having more people on this discussion rather than take a hasty decision ;-). Btw, I have some other ideas like suggesting y-, z- prefixes for proprietary and draft extensions (so that device makers can play around without messing with the x- namespace).--Satomi Ahn 16:21, 11 June 2009 (UTC)

Command syntax is very important, but it is also very important to keep from adding more types of syntax to check for. To check for !x- prefixing all the ORG commands requires a string search (or get and compare, which is just as slow), and adding !y- and !z- would increase the time needed just to find the commands. The way standard RLV commands work, !meta commands are handled by the relay, and @commands are sent to the viewer. For all intents and purposes, !x-commands are handled by the relay, so there should be no need to add more overhead.--Da Chrome 11:23, 13 February 2013 (PST)

This discussion is dying... and I believe this would be a big mistake not pursue it to its goal. Independently from what we decide in the end, I can easily already sort the different x-tensions of the current list into 2 categories without any ambiguity:

True meta-commands:

• who
• handover
• e-mail
• http
• channel

LSL effect commands:

• vision
• gender
• species
• freeze
• follow
• control
• listen
• message
• animate

The second category contains both commands that will enable/disable a behavior (like !x-vision/!x-vision-clear), and commands that will ask for some data (!x-get-gender). Maybe the second subcategory can be handled in a generic way by requiring that the asked data is actually the acknowledgement string (in this respect very similar to !version, !implversion and !x-orgversions).

My current view is that the LSL effect commands can be implemented by relay plugins whereas meta-commands are too much imbricated within the inner working of a relay to become a separate plugin. I believe this criterion alone could be enough to distinguish what is a meta-command and what is a LSL effect command.

Now that the distinction is clear enough (for me at least!), my argument for having a different prefix would be to make easy for a relay to distinguish between the two at a early stage for handling them differently (for LSL effects, that would mean transmitting the command to the plugin in a link message).

Moreover, LSL effects could possibly become viewer effects in the future, either without modification, or with a trivial conversion. The plugin architecture will make it easy to replace the handling of a given effect in a plugin by a LSL mechanism with a viewer mechanism when it becomes available, only replacing the plugin.

--Satomi Ahn 12:25, 24 July 2009 (UTC)