LSL Protocol/Restrained Life Relay/delay

This is a discussion page for adding support of delays in the execution of relay commands.

!delay

Not implemented yet

Description

meta command to pass a delay (in seconds) the relay has to wait before executing subsequent commands from the device.

Background

Most of world objects just lock you in on some fixed piece of furniture, and thus can easily ensure you will eventually be released of every restriction, as it will do it at the time you are allowed to stand up. Other devices have other ways to ensure you're eventually released: for instance, zone controllers use a sensor and send a "!release" as soon as you exit the sensed zone.

In both case, the device is still nearby from the beginning to the end. What about if you want to restrict someone in some way, but don't want to prevent them from leaving? It is currently impossible to do it while ensuring a timely release (or you have to rely on the fact that the relay verifies the device is still nearby and active).

Here I propose to add another way to ensure the release of restrictions, by delaying of some fixed time the execution of a bunch of relay commands (hopefully including a !release).

Syntax

!delay/(integer)

(integer) is the amount of time, in seconds, you have to wait before executing subsequent commands.

Other parameters after a second "/" should be ignored, as they could be used for a future extension.

Discussion

I still don't know if !delay should be applied on every subsequent command from the device, or only the ones of the bench of commands the !delay belongs to, thus allowing to affect the target while some commands are still pending.--Satomi Ahn 17:20, 21 March 2009 (UTC)

I think we need a way to modify delayed commands that have already been sent. --Maike Short 08:39, 22 March 2009 (UTC)

LSL http server or llEmail may be a better way to keep contact between the world object and the relay if the agent leaves the llShout area. But I have not look at that in detail, yet. --Maike Short 08:39, 22 March 2009 (UTC)

I haven't used llEmail but I heard it wasn't that reliable. Is it?

And what about http server? I see you commented the page, have you experimented with it? If the whole relay protocol could use http, then this "!delay" thing becomes useless (the capturing device could run a timer instead of the relay). But then, wouldn't we need a metacommand for requesting the URL? --Satomi Ahn 12:01, 31 March 2009 (UTC)

Other big issue: the URL will be disabled when going to another region, which kills the purpose of using http instead of chat (in our case)... unless the relay polls the capturing device, instead of the contrary.

Another issue, maybe, could also be the per-parcel URL limit (equal to the prim limit). --Satomi Ahn 12:11, 31 March 2009 (UTC)

Sorry for the late reply, I was too busy with my Easter Egg Hunt project, which unfortunately had kind of a deadline :-). Yes, you are right about the URL changing whenever the avatar goes to another region. I got that "url pool per avatar" wrong. That is just the for the URL limit. Email is pretty reliable nowadays in SL. They fixed the major bug that sometimes caused the email queue to get stuck until region reboot. --Maike Short 01:54, 13 April 2009 (UTC)

Let me recapture the goals

• 1. The avatar and/or the world object should be allowed to wander around while restricted. This means the avatar and the world object may get more than 100 meter away or one may go to different regions.
• 2. It should be ensured that the avatar is freed in the end.
• 3. The avatar should not be freed immediately but only after a specified time.
• 4. Some other changes to the restrictions/force-commands can be delayed (while out of range)?
• 5. Multiple delays should be supported?
• 6. The world object should be able to modify the delayed commands (when in range).
• 7. Old relays not supporting !delay should do "the right thing".

Current situations when out of range

• A. All relays will free the avatar immediately after relogging.
• B. Some relays will periodically ping the world object and free the avatar after a short time
• C. Some relays do garbage collection using the object distance when another world object tries to control it. This may free the avatar after a short time or after a long one, depending on the situation outside the control of the first world object

Simple solution (ignoring 4. and 5.)

• "!delay/(seconds)|!release"
• Relays not supporting !delay would free the avatar immediately so they don't get stuck.
• The command can be executed repeatedly to change the time while in range.
• Relays supporting !delay must keep the session in situations A. to C.

Problems

• I am not happy about not freeing on "relog without !pong".
  • We could have a second parameter saying whether relog should free. This does make sense when the restrictions are only set to keep the session open to prevent further ask-mode-questions. Or the world object is worn by the dom as remote control. He/She might what the submissive to be free when he/she is not around.
  • A relay might have a maximum timer after which it will free anyway.
  • World objects should be required to send the !delay/(seconds),!release again, after they added some immediate restrictions
• Requirement 4: other changes after some time
  • This means we do not simply have a !release after the delay but a complete chat line full of commands
  • All other meta commands that were introduced after the original version of the spec can be safely ignored: !pong, !implversion, !vision, !visionclear, !who, !handover
  • No problem as long as we have an !release at the end, which we should have
  • The worst case is that the avatar is freed immediately
• Requirement 5: multiple delays
  • requires a different syntax for adding delays and updating existing ones
  • hard to keep track of
  • a requirement should be that the longest delayed commands (those with the !release) are send (or repeated) at the end

Ignoring 5 would make things much simpler. How important is it? --Maike Short 01:54, 13 April 2009 (UTC)

Well, those are true questions. But why not take it she safe way: having most of the difficult points optional, falling back to a safer behavior in case it is not implemented: for instance if multi-delays isn't implemented, then always fall back to the first delay to finish. Also, having some devices whose restrictions should not be pinged on relog could be optional (thus falling back to the default that a relog clears everything which isn't nearby). Well, that is only a first reaction to your comments. I will read them more carefully when I have some time. --Satomi Ahn 18:13, 19 April 2009 (UTC)