LSL Protocol/Restrained Love Open Relay Group/forward
forward
STATUS: draft
version: 001
No implementation
Commands:
- !x-autoforward: secondary behavior
- !x-fwd: instant query
- !x-fwdnotify: primary behavior
Description
(better) Alternative to simwide. Asks the relay to forward viewer answers to RLV commands that expect an answer from the viewer. The forwarded message will use whatever communication channel (chat channel, or email, or http, or... ) was already used between relay and controller, ensuring the RLV controller is in range.
Raison d'ĂȘtre:
- llRegionSayTo is compelling enough that it is expected most relay will acknowledge every relay command through this LSL function. However its range (sim wide) is greater than that of the viewer answers (shout distance: 100m). Thus a mode where the relay forwards viewer replies with sim range is needed.
- Some extensions (email, http-in) make it possible for relay and controller to negotiate alternate means of communication and for instance enable gridwide communication. Then the same issue occurs. These x-tensions already provide their own mechanisms to relay viewer replies, but this current spec is the occasion to make everything consistent in a nice way.
Use
I propose two operating modes. A relay implementing forward x-tension must support both. Next updates on email and http-in will assume forward (both modes) as a prerequisite.
In both operating modes, when used in chat mode, all forwarded replies must be forwarded using llRegionSayTo (not much point in using llSay or llShout anyway).
First scheme (recommended for new devices)
This first operating mode is the lightweight one. Its advantage resides in the fact the controller does not have to care about channels concerning chat it cannot hear anyway. The controller just says it wants replies forwarded, whatever the means it was sent from the viewer to the relay. The viewer then relies on the command identifier to match replies to previous queries (instead of channel number).
Typical exchange with
- C being the RLV controller
- R being the RLV relay
- V being the viewer of the relay wearing agent:
C -chat on RLVRC-> R: outfit_query,!x-fwd/getoutfit R --llOwnerSay--> V: @getoutfit=9876 R <-chat on 9876- V: 0010011111111110 C <-chat on RLVRC- R: outfit_query,!x-fwd/getoutfit,0010011111111110
Special case of @notify:
C -chat on RLVRC-> R: notify_outfit,!x-fwdnotify/worn C <-chat on RLVRC- R: notify_outfit,!x-fwdnotify/worn,ok R --llOwnerSay--> V: @notify:9876;worn=add ... R <-chat on 9876- V: /worn legally shirt C <-chat on RLVRC- R: notify_outfit,!x-fwdnotify/worn,/worn legally shirt ... R <-chat on 9876- V: /unworn legally pants C <-chat on RLVRC- R: notify_outfit,!x-fwdnotify/worn,/unworn legally pant ... C -chat on RLVRC-> R: unset_notify_outfit,!x-fwdnotify/clear/worn C <-chat on RLVRC- R: unset_notify_outfit,!x-fwdnotify/clear/worn,ok
Notes:
- as no channel is specified, it is up to the relay to decide which to use, or even not use chat at all. This makes a lot of things possible
- use of viewers using http-in instead of chat for viewer replies to the relay
- RLV full emulation in LSL with nothing viewerside
- maybe fancier stuff (relay proxies?)
- since no channel is specified, in relay syntax this command part cannot be sent as a "@" command, because it cannot be transmitted as such to the viewer with no translation. So it had to be encapsulated into a new "!" command ("!x-fwd"), and thus it is now explicit which @get* commands should have their replies forwarded or not. This is why there is no persistent on/off switch (in contrary to the second operating mode).
- About !x-fwdnotify:
- this is a bit an adhoc command, maybe something more general will be needed if RLV gets more commands like @notify
- what about if we want to be notified about the "clear" keyword?
- forwarded notifications are encapsulated in a too verbose syntax. Should we simplify it and sacrifice the mandatory 3 ","'s? Or does it really matter if this is verbose?
Second (legacy) scheme
Second operating mode is similar to (and compatible with) mechanisms already proposed in email and http-in, and not very far from simwide (with the difference that the controller does not open a new listener).
Typical exchange:
C -chat on RLVRC-> R: enable_forward,!x-autoforward C <-chat on RLVRC- R: enable_forward,!x-autoforward,ok C -chat on RLVRC-> R: outfit_query,@getoutfit=1111 C <-chat on RLVRC- R: outfit_query,@getoutfit=1111,ok R --llOwnerSay--> V: @getoutfit=1111 R <-chat on 1111- V: 0010011111111110 C <-chat on RLVRC- R: 1111,0010011111111110 (1) C -chat on RLVRC-> R: disable_forward,!x-autoforward/clear C <-chat on RLVRC- R: disable_forward,!x-autoforward/clear,ok
(1): this message does not conform to the grammar of a relay message in the basic spec, but as it is meant to be sent on a private channel (llRegionSayTo or email, or http-in), this is no issue. Moreover this is the current syntax for viewer replies forwarding in email and http-in modes. Thus this amounts to say that !x-autoforward is enabled as soon as email or http-in modes are active (no need to send !x-autoforward in these modes).
The relay should use the channel number specified by the controller in all case and dutifully forwards the RLV command exactly in the form given by the controller (in the example: "@getoutfit=1111"), as stated in the basic requirements. However, if for some reason this cannot be done, but relay and viewer have other means of communication, the relay can just pretend but in this case acknowledge "@getoutfit=1111" with "ko".
It would go the following way:
C -chat on RLVRC-> R: outfit_query,@getoutfit=1111 C <-chat on RLVRC- R: outfit_query,@getoutfit=1111,ko R --some other mean--> V: @getoutfit[=maybe something] R <--some other mean-- V: 0010011111111110 C <-chat on RLVRC- R: 1111,0010011111111110
Other point: if autoforward is enabled, "@notify:channel;option" sets a permanent listener on that channel in the relay, and the relay will forward everything that comes from the viewer on this channel to the contoller.
C -chat on RLVRC-> R: spy_outfit_changes@notify:1111;worn=add C <-chat on RLVRC- R: spy_outfit_changes@notify:1111;worn=add,ok R --llOwnerSay--> V: @notify:1111;worn=add ... R <-chat on 1111- V: /worn legally shirt C <-chat on RLVRC- R: 1111,/worn legally shirt ... R <-chat on 1111- V: /unworn legally pants C <-chat on RLVRC- R: 1111,/unworn legally pants ...
Interaction with !x-takeover, !x-handover
... to be specified...
The first scheme is oblivious to these issues. For the second one, it must be decided whether autoforward mode should persist when the token is passed to another device.