Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

While I preferred the name !x-tensions (yes, I liked the pun), !x-orgversions is fine by me. I am not sure what the version of ORG will relate to, but it won't hurt to put it into the spec.

The requirements on relays are not onerous. I am for this and, if approved, will withdraw the !x-tensions proposal. --Chloe1982 Constantine 13:15, 18 July 2009 (UTC)

Being the one originating this proposal, it is obvious I vote for it too. Now, why voting for this? It is more than the requirements per se that are important, but acting the principle that

1. ORG does not only proposes extensions but also fixes some breaches in Marine's spec
2. everything ORG proposes, being the optional extensions or the fixes in the core specification has to be versioned
3. versions of core specification are necessary for the same reasons as the RLVR spec are versioned. Moreover, if Marine ever reads those fixes, maybe... maybe some day she will fix her spec, and then we will be able to remove this from ORG.

For the future of the core requirements, sometimes I wonder if I won't rewrite the RLVR protocol from scratch, making it both easier to read and more precise than it is now, while preserving compatibility (someone pointed to me that Marine's spec actually left a lot more implicit things than I thought: it is not even clear that every "@" command should be acknowledged, actually! Neither are the meanings of "ko" and "ok" explained).

--Satomi Ahn 09:56, 19 July 2009 (UTC)

All looks good from here, no objections or complaints... rock on.

--Ilana Debevec 18:52, 19 July 2009 (UTC)

I would suggest handling the "unrestrict when out of range" problem differently. Susan Daviau currently provides a proprietary extended mechanism for restricting someone who may go out of shout range. This sort of extension requires a communications mechanism that is not restricted by llShout distances - email, or http requests for instance provide cross-sim control.

((Correction)). I see that such a proposal is in the works , an e-mail extension. If someone is using this extension, I don't think we want restrictions automatically dropped when they get out of range.

In addition, if we want to get Susan Daviau on board (has anyone contacted her?) it might be good to make org extensions compatible with her products.

I am not sure how to reword the specification exactly.

I also am somewhat in favor of making the range check a function that the relay wearer can trigger, rather than automatic function. For instance, I might wish to allow someone to restrict me with a portable control device and wish to honor the restrictions even if they go out of range. Making the out of range check more interactive and manually triggered would make this possible.

Nano Siemens 00:12, 20 July 2009 (UTC)

Concerning Susan: I don't know if she was contacted. I believe she should be.

My proposal about releasing restrictions was only for unreachable controlling devices. If the relay is using e-mail, then the controller remains reachable from other sims (although it is less easy to check).

Should the wearer trigger the function by hand? Well I don't know. Let's reword the requirement, then: "make it possible for the wearer to be released if the controlling device is not reachable" and not specify if this will be done automatically or called by the wearer.

Concerning portable devices: currently the issue is that after teleporting, even if you come back, you cannot release the relay, as the portable device UUID has changed. Using e-mail can circumvent this. Other mechanisms can be considered.

As a side note, everything that is done by email up to now could from now on be implemented using http-in. I don't know what are the compared advantages of the two approaches, but anyway I will eventually write a !x-httpin extension.

--Satomi Ahn 14:10, 22 July 2009 (UTC)

I like Satomi's suggestions, and have taken the liberty of attempting to reword the specification to incorporate them. Nano Siemens 22:37, 23 July 2009 (UTC)