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.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
