|
|
|
[
Permlink
| « Hide
]
Argent Stonecutter added a comment - 11/Jan/08 07:55 AM
Closing, duplicates MISC-388.
MISC-388 would allow residents to implement this functionality, with the "suspended" membership information stored in the script or in an external database (eg, via HTTP request to a website).
See "VWR-11988 Group Holding Buffer "
I would disagree with part of the implemented processes as I don't see a need to give up any of the rights of group membership other than the use of Group IM and Group Notices. I would think it should be possible to simply set a flag as either "Opt-In" or "Opt-Out" and yet still have the ability to manage group land, media, permissions, etc. I suspect that the relationship of the avatar's profile to either a sim, parcel, or object is determined by the server at the point of interaction rather than being a matter of putting excessive load on the database. That being the case I would assume that for each group there is probably about 7 primary tables that are used to control (I haven't see the source code nor looked at OpenSIm so I'm not 100% positive on this) Group I would think that if you brok the Group_Members table up into two (Group_Members_In / Group_Members_Out) that you could do two things 1) Reduce the load by allowing people to only Opt-In to a maximum of 25 groups, and In this way you can not only reduce the load on the database for notices and IMs to only those people who both want IM/Notices and Opt-in to that as one of their groups, but you can further reduce this by moving all non-essential communications into an Opt-Out state which I would think dramatically reduce load on the server just through attrition of accounts alone. That should more than make up for the minimal increase in processing requirements require to manage the Opt-In and Opt-Out Lists. isn't the land etc permisions what makes up the most of the load caused by bigger amounts of groups per person?
also, I don't like having msgs stop coming if I don't log in often enough, somtimes RL gets in the way but I would still like to be able to be contacted by people and be informed of things that might make logging in have more priority than other RL stuff Its IMs and Group notices as far as I know.
If land permissions are putting a strain on the database server then they've likely badly designed that part of the interface. Essentially what should be happening is that the client is served a unique token (one-way hash to prevent tampering) which stores group permissions on the client's computer. The sim then simply keeps track of the group token for comparison purposes based on role assignment. Since roles are limited there the size of the table on the server should be managable even if we were to get another feature that we really need which is multiple groups being given access to a land parcel (currently this is only available at the sim level). The other alternative is to have a separate database which controls only the group permissions which distributes the load more evenly. Regardless, if the token has changed then a call to the main database is made to retrieve the new token and new permissions - the information is uploaded to the client and away we go. As far as the limitation on messages go - it only takes 5-10 minutes to log in and log out. If someone hasn't logged into Second Life for a period of 3-4 months of more - chances are they aren't really keeping up with what is going on in their groups anyways. Maybe there could be like a monthly digest of all notices send to people who are in the Opt-Out list. I dunno but I do know that I prune our group list on a regular basis using 12 months as the cut off point as two years ago all the groups were fubar'd for close to 6 months due to system not being able to appropriately serve IMs and Group Notices to groups having more than 500 people in them. Today we have groups with 4000 or more. You get even a quarter of that number online at the same time and the number of interactions between members is enormous. Both permissions and IM/notices have an impact: Robin Linden wrote "Group related queries and operations are currently among the most complex of our database operations that happen 'on the grid.' The more groups Residents can join, the more complex these queries become-- there are more groups, more group-to-agent relationships, and more 'roles.' Because of this, increasing the groups limit could affect the performance of the grid, so it's something we need to consider very carefully before moving ahead."
But there's certainly no reason Linden Labs couldn't allow suspended groups to still count for permissions if that isn't still an issue. In fact that's part of this proposal as well, so VWR-11988 is a duplicate of this proposal (and it's misfiled as well, this isn't a VWR issue). As an aside, looking at OpenSim wouldn't tell you anything about Linden Labs implementation. There is not a single line of code in common... they're not even in the same language. I must admit that suspending a group seems so obvious that I don't know why it isn't implemented.
A fair number of groups I belong to are those of family and friends and give me various degrees of access to their land. But .. I may only visit them once a month. So .. I have a group that only needs to be active once a month. Iwould love to have the ability to suspend that group. If I needed to visit my friends I could bring it out of suspension |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Normal
Allow users to suspend groups or group functionality
