[Opensim-dev] Test before you call OSSL function

[Mike Higgins]

I am trying to write a new OSSL function osPermissionToCall(string 
function_name)

I want to be able to call this function before calling other OSSL 
functions to find out if I can call them. Then I can give meaningful 
error messages to the users of a script, or use alternate functions. 
Without a test-before-calling, most of the OSSL functions SPAM EVERY 
AVATAR IN THE REGION with an ANGRY RED ERROR MESSAGE on the DEBUG_CHANNEL.

In OSSL_Api.cs there is a function CheckThreatLevelTest(ThreatLevel 
level, string function). I thought this would be the solution, but it is 
lacking. I know because I already wrote and tested a new OSSL function 
that calls CheckThreatLevelTest and it does not work right for this purpose.

Each OSSL function calls this check with a hard-coded threat level in 
the first argument, and its string name in the second. For example:

CheckThreatLevel(ThreatLevel.Moderate, "osGetGridName");

Each OSSL function is required to know what its threat level and string 
name are and to send those to CheckThreatLevel (which calls 
CheckThreatLevelTest to do the test). There is no database, table, ini 
file or xml file that knows what the threat level is for each function, 
how many functions there are or what their names are. 
CheckThreatLevelTest builds a cache in a Dictionary named 
m_FunctionPerms but it only stores the avatars, creators and classes 
that are allowed to call it, and only if those things are mentioned in 
the ini files.

If a function is not mentioned in the ini files, it is added to the 
dictionary cache with default Allow everyone, and only the threat level 
is used to determine if it can be called. Since you don't know the 
threat level of each function, there is no way to find out before hand 
except to call it and get an exception if it is not allowed. When an 
exception happens, every avatar in a region is spammed a red error 
message on the DEBUG_CHANNEL. This is very annoying.

If you ask about a function that does not exist, (like “osTickleBunny”) 
it is added to the Dictionary with Allow all. Since it doesn't have a 
threat level it will always test OK to call. This means you cannot use 
CheckThreatLevelTest to test to see if a function exists in your version 
of OpenSim.

What can be done about this? One solution would be to add the threat 
level of each function to the ini files. The OSSL functions would no 
longer need to know their threat level. During initialization, 
OSSL_Api.cs would iterate over all the names in the [OSSL] section of 
the ini structure and pre-populate the Dictionary. The ini file would 
need to have new lines added to declare the threat level of each OSSL 
function. If a function does not have a threat level line, it is assumed 
to be THREAT LEVEL SEVERE. The CheckThreatLevelTest function would be 
greatly simplified since it would not have to populate the Dictionary 
on-the-fly. If an OSSL function is not mentioned in the ini files, it is 
treated as a non-existing function and cannot be called. Then my 
osPermissionToCall() function could be written to check the Dictionary 
for the existence and permission levels of an OSSL function.

The problems with this solution, and why they are easy to overcome, are:

1) Everyone would be encouraged to upgrade to a new ini file with threat 
level lines added. The Master branch has and uses a file named 
osslEnable.ini that has default Allow permissions and could be upgraded 
to have the new lines. The distribution kit that OSGrid builds already 
includes a copy of that file and would get the new one from Master.

2) People who do not upgrade to this file may notice that all OSSL 
functions are down-graded to threat level SEVERE. Since the threat level 
is only used when an OSSL function does not have an Allow line in the 
osslEnable.ini file, and existing copies of that file do have Allow 
lines for most of the functions, people still using the old 
osslEnable.ini file might never notice.

3) Some regions, like the LBSA Plaza region on OSGrid for example, do 
not use the osslEnable.ini file at all and depend solely on the current 
hard-wired threat levels. They will be unable to call any OSSL functions 
and need to start including the osslEnable.ini file.

4) People who have carefully edited their osslEnable.ini files to 
control who can use each OSSL function would have to carefully merge 
their old osslEnable.ini file with the new one. This is a recommended 
procedure with all new versions of OpenSim anyway.

5) There is a group of OSSL functions that do not call CheckThreatLevel. 
These functions will continue to work as is with the old osslEnable.ini 
file. However, my proposed osPermissionToCall function depends on the 
ini file to populate the list of functions. It would return a false 
negative if anyone asked it about these always-safe-to-call functions 
with the old ini file. Since nobody is calling my new function yet, most 
people would not notice. Those that do notice, can upgrade to the new 
osslEnable.ini file which would have a line for each of these 
always-safe functions.