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.
Finally a resolution.
Nexii made his own groups, which are pulled from my.secondlife.com, see here: http://chromebackend.net/s/Groups/
I don’t think it is hard for LL to do it, at all.
Interesting. May be I’m missing something, but unless he can persuade people to provide an email address I’m not sure how much use a Google group will be. It seems like a better Subscrib-O-Matic.
Lemme just crosspost some of what I wrote in the jira:
‘Not to be overly optimistic, but this may not be the death of SCR-79. I think what Kelly Linden was talking about were the more in-depth functions like SVC-199, where respecting all privacy flags is an ABSOLUTE MUST for the function to be even considered. This function on the other hand may not require privacy checks.
From a technical standpoint this function should still be doable. Why? Well for one, the Sim HAS TO know your group; otherwise llSameGroup() wouldn’t work. Same goes for llGetObjectDetails(), which according to Kelly Linden herself “is a 2 line fix to make it work for agents.”‘
Basically, this looks like a problem for privacy, not functionality. We won’t get the fun functions people wanted to just list EVERY group a person was in, or match against those groups, things like that, but we could still get relatively simple things like SCR-79.
I hope you are right.
One more good reason why Linden Lab needs to do a complete overhaul of groups, as I have been advocating for some time ( http://bit.ly/otlKJp ). As they are, groups are no longer up to the task as a communication tool. The membership management is basic, chat insufficient and inefficient. There is no way to store information, no way to use groups as forum support tools, which would be great to relieve the chat servers. You can’t even change the name or close a group.
Groups should be web-based, have a web-based home page, have a mini-forum, possibly a wiki and a file library. Optionally, they should be open to the web: think of the thousands of special interest groups promoting SL on the web for free!
Too costly? Make it a basic version for everyone, a full version for premium members. That would really add value to premium membership.
I had not thought about it that way, but yes. I had stopped at ‘what a PITA’.