delay

STATUS: draft

VERSION: 004

Version 003 implemented in Satomi's MultiRelay HUD 1.02b5

Version 003 implemented in Dahlia's MultiRelay 1.0beta10

Version 004 implemented in Dahlia's MultiRelay 1.2.22

RECOMMENDED WITH: cancel

Possible uses

!x-delay/1800|@remoutfit=force: Will strip the victim in half an hour.

@sendchat=n|!x-delay/600|!release: The victim will be mute in chat for the ten coming minutes.

!x-delay/600|@sendchat=n|!x-delay/600|!release: In ten minutes, the victim will be mute in chat for the next ten minutes.

Syntax and semantics

Commands

• !x-delay/TIME[/IDENT[/MODE]]: delays the remaining subcommands of the command by TIME seconds. Store the bunch of subcommands in the relay event queue, along with the general identifier of the relay command. Optionally, we can specify the string IDENT and it will be used instead, and a timer mode MODE. In current version MODE is either "online" or "real" (default is "online", and if the requested mode is unknown, the relay should failback to the default).
• !x-delay/clear[/PATTERN]: clears all commands in the relay event queue which have an identifier with PATTERN as a substring. Clears all delays related to the source if PATTERN is not specified.
• (DEPRECATED)!x-delayclear[/PATTERN]: synonym of !x-delay/clear. Should be removed in the next version.

Formal key points

• Timers should be restored on relog/reattach. Remaining delays of every "online" mode timer should be postponed by the amount of time spent offline/detached. Actions corresponding to expired "real" timers should all be executed on relog.

• Devices with running timers should not be pinged on relog but only when the last of their timers expires if any restriction still remains.

• !release should clear all timers related to the device. This is a case where @clear and !relase behave differently: @clear clears current RLV restrictions, but the absence of active restrictions does not mean the relay is released: indeed running timers (which are not RLV restrictions) may still exist and restrict the wearer later.

• obviously, !x-handover, if it is asked that restrictions are transfered, should also transfer all remaining timers to the device control is handed over to.

Informal key points

The potential of surprise of !x-delay is something that should be kept in mind while designing relays. Thus it is recommended that the mere fact of setting a timer be not considered a locking action in the following sense:

• !x-delay commands should be accepted with no particular auth check, especially if that check involves a question to the wearer (typically: Ask mode). Any interactive steps should occur only when the first (meta-)command that actually does something is about to be executed (i.e. after the timer runs out).
• If the relay has a feature to list current sources to the wearer, then the fact, for a source, of having a running timer should not be a sufficient reason for being listed.
• Having a running timer also should not be a sufficient reason to make the relay undetachable.

However, for the two following points, a source with only timers should not be ignored:

• Safewords, if we consider them as user triggered !release, should also clear timers.
• A source with timers is, in some way, in the relay's directory and informations relative to that source and used by x-tensions such as email, http-in, channel and ack should be stored and kept up-to-date when possible.

Remark: with respect to the definition of locking action in ORG core requirements: and what it implies in that document, it does not change anything whether we consider that setting a timer is a locking action or not.

However, in the light of the present document, it should be considered locking where !release, !x-handover, safewords and directories are concerned, but not locking where visible effects are concerned (auth dialog/ask mode, listability, undetachability). This calls for two distinct definitions for known source and locking source. Maybe ORG core requirements should be updated to reflect this distinction.