LSL Protocol/Restrained Life Relay/who

From Second Life Wiki
< LSL Protocol‎ | Restrained Life Relay
Revision as of 13:38, 23 February 2009 by Maike Short (talk | contribs) (splitted out of https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Life_Relay/Bugs_and_Pendings_Features)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is a discussion page for adding support of the controller of an device.


!handover proposal

Proposed Change
Add meta command !handover/key/type
Justification
There should be a way to handover the victim from one world object to another without the having to ask for permission again
Requirements
The change must enable world objects to be easily compatible with both old and new relays. The relay must ensure that the target object is ready.
Syntax
!handover/(key)/(type)|!release
(key) is the id of the target object
(type) : 0 lift all restrictions of the source object, 1 keep them, it is the responsibility of the target object to keep them in mind
Compatibility
Immediately after the "!handover" a "!release" command must be sent by the world objects. Relays which support !handover must ignore the rest of the chat line, including that !release command.
Old Relays which do not support "!handover" will ignore it and execute the "!release" command instead. So they are available for the target object in the old way (e. g. may ask for permission again).
The relay must ignore further "/"-parameters for future extension of the command.
Note on ping/pong
The relay must ensure with the !ping meachnism that the target object is available. The target object, however, might not see the ping, for example because of a slow intersim teleport. The target object must respond to !pong on arrival anyway.

Alpha Code

TODO
Think about an additional "/"-paramter meaning "let that target object control the relay but keep me on the list, too" for relays that support multiple world objects. This needs a bit more of thinking because the policy of ignoring !release does not work this simple anymore. Since Dominatech's sample code is under a very restrictive license, i am unable to look at it, to see who much work this would be. --Maike Short 08:54, 15 February 2009 (UTC)
3 way handshake
This is a GREAT idea that perhaps should be expanded a little.. "Handover" (to me) implies "here, take this", "ok I got it, thanks". So perhaps this should be three commands? A !handover-r (request), !handover-s (send) and !handover-a (ack) something like -
sent to source object that has to do the handover - !handover-r/target-key/(type) (request you hand restrictions you have to target-key)
sent from source object to the target object - !handover-s/target-key/(type)/(list of restrictions in effect)
sent from the target object back to the source object !handover-a/target-key/(type)/0 (0 = handover accepted) -OR-
sent from the target object back to the source object !handover-a/target-key/(type)/-1 (-1 = handover failed)
the source takes whatever actions necessary depending on the success or failure of the handover. Just thinking out loud. --Ilana Debevec 02:22, 17 February 2009 (UTC)
Unfortunatally, there is a situation in which this won't work using normal chat: The first objects sends @tpto:././.=force|!handover/./.|!release. The tpto destination can be in another sim anywhere on the grid. There is such an object called "Kidnapper" in Stonehaven at <76, 202, 11>. --Maike Short 19:38, 17 February 2009 (UTC)