In my article #SL News Update Week 24 I wrote about SCR-79 and a possible new group matching function.
Many tasks in Second Life® would benefit from a better function for group membership checks. It would help scripters and residents. Residents would not have to pay as much attention to which group they have active. Scripters would not have to deal with getting residents to change their active group to get free group gifts or access to restricted locations.
But that is not to be. Kelly Linden was hoping to be able to add a better group check. Kelly relates what he found. I’ll try to explain provide context for the decision after the quote.
So I had a look at doing *something* about scripts determining groups an agent [resident/avatar] is in. And I found much, much sadness. Basically we can’t do anything. Sorry!
There are 3 different privacy options for groups that determine whether someone else should be able to know if you are in a group. The first is easy – the option everyone has in group preferences for whether or not the group shows in their profile. The sim knows this, so LSL could know this.
The second is moderately hard: in the DB there is a per-group visibility flag. The sim doesn’t know this, but it could find out and use it with some work. If this option is set the group doesn’t show in profiles or search no matter what the per-avatar setting is. [This is not the same bit of data as in the first case.]
But the last one is the truly horrible one, as far as LSL is concerned. The web-based profiles have their own option, stored in their own (mongo) DB in their own system. Not only is it extremely difficult to get that information into the simulator but the options it has are hard to implement: visible to world (easy), all SL (easy), only friends (essentially impossible). Even if we just treated ‘only friends’ as ‘hidden from LSL’ the combination of that and the DB access suddenly turn it into a HUGE project.
The end result being: it is too large a project for the foreseeable future to add any more LSL access to avatar group information.
I’m probably gonna do a really sad run through the dozen or so jiras and close them all as ‘someday maybe’ or similar.
So, detecting group membership is going to remain a tedious process.
I’ll try to put the problem in non-computerese terms and provide some explanation and context. I’ll have to make some guesses, but I think I’m close.
The new profiles and social web pages creates a complex set of privacy issues not previously present in-world. The addition to let your friends see your membership in a group or not, is new and arrived with web profiles.
The problem is in getting that new information back into region server. It is no longer a just matter of whether you allow your membership to be shown. If you allow friends to see hidden groups then the new function would require the server to figure out who all your friends are. Then the function has to figure out if the owner of the scripted object asking is a friend of yours.
Basically it is getting complex and requires connecting to data source not normally used by the region server. Remember. The profile you see in the viewer is just a web page. The region server only has to provide the HTTP pipeline. The web profile server does all the data query and processing. The viewer’s built in WebKit browser displays the data feed in.
If a new group matching function were to be added in, the server would have to duplicate much of the processing the web profile servers handle. That is unlikely to happen as we need the region servers as lean as possible. The Lab’s goals seem to be to move as much processing off the region servers as possible.