I have already written an OSSL function to expose that internal code
that tests permissions from a string version of function name. It is
unsatisfactory because it cannot tell which functions will fail because
of the threat level. It can only tell you if it passes the "Allow_" test
from the ini file. I am considering two solutions: 1) Adding "Threat_"
lines to the ini files for each function or 2) Moving the threat level
into an internal table that the test-before function can access.
(Currently the threat level is a hard-coded constant in each OSSL
function). Which would be preferred?
On 10/14/2019 2:04 PM, Melanie wrote:
The original intention of the LSL permissions system was to make a script fail
catastrophically. Subsequent edits have made it so that using a not allowed
function would not crash and stop the script, which was the original, and back
then intended, behavior.
The history of this is that it should be impossible for a script to detect that
it is not running in SL, as an attempt to prevent the creation of multi-grid
griefing scripts.
The threat of griefing never materialized as the SL griefers proved to be
uninterested in OpenSim.
Still we're stuck with this legacy. However, as was said, there isn't an obvious
"invalid return" for some of the functions and, worse, some don't return a
value and expect the user to assume the call has succeded.
While I have been, at the start, an opponent of discoverability, I've since
changed my mind and I believe a querying function for script permissions is the
logical step to take. The internal code is already able to determine
permissions from a string version if the osFunction name, exposing that would
be quite trivial.
Also some "safe" functions that used to be subject to permission checks, aren't
anymore.
So this gets a +1 from me.
The donated xmrEngine, which is now YEngine, also had, at the time it was
donated, a try/catch mechanism. I am not aware of how much of that remains
after the removal of the extension APIs and the linux-only parts that caused it
to become YEngine. However, until it, or it's successor(s) become the standard
engine and any engines not able to use try/catch are removed, the API can't
really make use of it.
- Melanie
---- On Mon, 14 Oct 2019 19:42:56 +0000 Haravikk <mailto:open...@haravikk.me>
wrote ----
On 14 Oct 2019, at 15:12, dz <mailto:d...@bitzend.net> wrote:
just an observation from a casual observer with decades of software
design experience...
Wouldn't it be more productive to wrap all OSSL function calls in error
handling so the response is "correct" regardless of the permissions?
Adding another seperate function that will ALWAYS need to be called
before any OSSL function just adds bloat, confusion, and removes any
incentive for the problem to be handled "correctly"
(looks at the forum name) OOO ya nvm…
The problem with that is that a default return value may not be distinguishable
as an error; for example, for a function that returns a list, an empty list
might make sense, but you wouldn't be able to tell if the return was genuinely
empty, or the call wasn't allowed.
In an ideal world we'd use C# or another language with exception handling, as
that's a much cleaner way to handle capturing of recoverable errors. Of course
it's also a lot of work.
I wonder though, how difficult would it be to expose a minimal version of
exception handling to LSL? i.e- a very basic try/catch block (no multiple catch
blocks, or catches of specific types, just catch everything)?
On Sun, Oct 13, 2019 at 10:27 AM Mike Higgins <mailto:m...@kayaker.net> wrote:
Yeah, there is an example of that crash and recover trick at
http://opensimulator.org/wiki/Threat_level, at the bottom of the page.
I have done that and it works after SPAMMING EVERY AVATAR IN THE REGION
once. Which is still annoying.
On 10/13/2019 4:25 AM, Michel Beauregard wrote:
Its a good idea to have a function that test if a osl function is
available to a owner in a specific location.
For now there is a way to test for osl function scriptwise. A failing
osl function cause a crash of the event calling it. So what I do is on
state_entry I call a timer with a fake call to all the OSL function(s) to
be use in my scripts . If the timer failes it means that one or any of the
function I need is not allowed . And the script simply spell out to the
owner of that object that it cant be use and abort. So at least it does
not repeatedly spam the region .
I will post an example of the script I use in my user page in opensim if
you like more detail. (http://opensimulator.org/wiki/User:Gimisa) . With
your function you might be able to detect the failure of the osl function
call instead of sending it to report inworld and act by sending back a
message to the script for action. Allowing me to use the reply in any way I
need instead of using timer failure.
hope it helps
GiMiSa
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
