[Opensim-dev] Test before you call OSSL function

[Mike Higgins]

I agree that many functions are dangerous, and some grid owners may 
shoot themselves in the foot by enabling them. But I am talking about 
writing scripts that behave in a professional way, so I can hand them 
out for lots of people to use. If I wrote a phone app that popped up 
internal error messages in some locations, this would be considered very 
unprofessional and people would down-vote my app and stop using it. Most 
programming languages have a try/catch (or on_error) flow control 
construct, but LSL does not. I would love to add such a construct to LSL 
but I do not have the skill to add that to the language. (I'm of the 
opinion that a new error event rather than an error state is the way to go).

I do have enough skill to add an osPermissionToCall function that 
returns some information about the OSSL functions. I agree this is not 
ideal, but I could write the code for this function and submit it to the 
Devs, saving them from needing to do this trivial task and saving them 
from the more difficult task of adding error catching to LSL. Ubit tells 
me he would reject this try-before-you-call submission. But I assume he 
does not have the time to do the better option of adding an on_error() 
state to the language. The result is that there is no way for us 
scripters to write professional programs in OpenSim.

Here is the scenario I am looking at: I write a useful script that 
people want to use as they hypergrid around. I thought it was safe to 
call osGetGridName which seems an innocuous function and will probably 
be allowed everywhere. But it turns out that osGetGridName has a 
"moderate" threat level and some places, (most notably LBSA Plaza in 
OSGrid), have the threat level set to "Very Low" and do not have an 
“Allow_” line to override this for osGetGridName. So my script works 
most places in the Metaverse, but fails and pops up messages when one of 
the users of my script shows up there. I would love to catch that error 
and do something reasonable with it. But LSL has no way to do this and 
the developers are resisting alternative ways to do this. (In the case 
of osGetGridName, I could catch the error and substitute “OpenSim” as 
the grid name, or have the script tell my users “Sorry, I can't tell 
where you are now”).

There was a secondary issue that when osGetGridName fails, it not only 
popped up an internal error message, but it sends that message to every 
avatar in the region. Ubit has thrown me a bone by adding an option to 
the INI files that suppresses this behavior and only sends the message 
to the user of the script. This has several problems: 1) Note that it is 
the user of the script that gets the message, not the scripter. 2) Most 
of my users and most of the avatars that get this message are that: 
USERS, not grid owners who have the power to change the INI file. Since 
they can't effect the outcome, they will stop using my script. And all 
scripters like me will just stop calling ANY of the OSSL function in the 
scripts we hand out. Even the innocuous looking ones. And all the effort 
that the Devs have spent on writing the OSSL functions will have been 
wasted.

Imagine that I write a phone app that works fine on the SPRINT network 
but pops up internal error messages when you are roaming on AT&T. But 
then it paws through my contact list and also sends a copy of that 
incomprehensible error message to all my friends. Ubit has given me 
equivalent of a tool that can stop that last behavior, but only if 
SPRINT and AT&T change some internal flag on their servers. Unlikely to 
happen. People are still going to get error messages and stop using my 
phone app.

Then there is an additional problem: Currently there is no way for an 
osPermissionToCall function to know what the threat level is for any of 
the other OSSL functions. That threat level is hard-coded into each 
function. Ubit resists moving that information to a central location in 
the code. He also resists moving this information into the INI files. 
But I still want to find a way to write professional scripts on OpenSim.

So if you are still reading this Ubit: Would you accept a patch with an 
osPermmissionToCall function that was completely self contained and did 
not require changing the location of the threat level values? For 
example, the osPermissionToCall functioin could have a local table of 
all the other functions and their threat levels. This might introduce 
bugs if threat levels ever change, but that seems unlikely.


On 10/17/2019 8:10 AM, Leal Duarte wrote:
> Well lets try put some perspective on this...
>
> The problem is not how hard it is to detected and handle disabled 
> functions
>
> The problem is WHY are you using them !!!
>
> See OSSL got a lot a functions in time and for very different reasons.
>
> Many are there because they are just funny/useful on very specific 
> regions or cases.
>
> Once the allow control was introduced, that got worse, because as dev 
> in can just not care, i just flag a specious feature as SEVERE, 
> ESTATE_OWNER only. And just let you change it and shoot your own feet, 
> or worse someone else feet...
>
> And in many cases you are just doing that. ( the C# scripts was a 
> example i just had to kill )
>
> see a very simple and useful(?) example
>
> osGetNotecardLine(..)
>
> none of that Dataserv mess of llGetNotecardLine(..) right?
>
> well wrong.. Dataservice is need because the notecard may be on a 
> assets server on the other side of the world...
>
> and not using it will stall the engine thread, potentially all of then.
>
> Why do i see its  errors at osgrid LBSA ?
>
> A lot more examples, but you got the point.
>
> When one writes a script, one must take in consideration its target 
> audience..
>
> you can't use osSlerp()  if you want it to run at current Kitely, can 
> you?
>
> So issue is to identify a set that should be universally supported, 
> and everyone make the effort to support it.
>
> ...
>
> Ubit
>
>
> On 17-Oct-19 15:17, dz wrote:
> ......
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev