
| Key: |
SVC-280
|
| Type: |
New Feature
|
| Status: |
Open
|
| Priority: |
Normal
|
| Assignee: |
Unassigned
|
| Reporter: |
Haravikk Mistral
|
| Votes: |
30
|
| Watchers: |
4
|
|
If you were logged in you would be able to see more operations.
|
|
|
As I understand the current system, simulators download information (mostly permissions) for ALL of a user's group on log-in. This is part of the reason why it took so long to give us more, as this information then needs to be passed around between simulators so that they can track our group permissions.
This seems a bit excessive however, as I may enter a simulator which doesn't contain land owned by any of the groups I'm in, or only a few of them.
The suggestion therefore is that simulators download group-permissions on an as-needed basis depending on where you are. So if I'm on my home land, it will download the appropriate group for that. Then if I move to other land, and am in that group, it will download that. In this way the simulator only really needs to cache a handful of groups, and simply throws away the last used chunk of data if a new one is required and the cache is full. For example; I reckon few people would wander around with more than say three groups they need to be tracked for in any given simulator, it could always cache more and simply timeout unused ones in the event that a user is constantly passing through different pieces of group-land.
This group download can even be restricted to when it's necessary, ie; if my land only restricts object-creation, then my group info is only needed if I try to create an object, so download it then, as I may not create any objects at all!
This may add short delays to some operations during peak network activity, but you're likely to have a little latency then anyway. It also means that there is no longer any need to restrict groups at all, as only the client cares about other groups, it can download the full-list separately like inventory which the user can then use to access group info/accouncements etc, and register its availability for group IMs or however that works (presumably the sim may do this at the moment, but there's no reason the client couldn't, just needs checked somewhere).
So, unlimited groups, less information needing to be tagged onto avatars to pass between sims, meaning improved border crossing. I doubt it'll fix it completely as there are likely other issues, but the less data you're sending around, the better.
|
|
Description
|
As I understand the current system, simulators download information (mostly permissions) for ALL of a user's group on log-in. This is part of the reason why it took so long to give us more, as this information then needs to be passed around between simulators so that they can track our group permissions.
This seems a bit excessive however, as I may enter a simulator which doesn't contain land owned by any of the groups I'm in, or only a few of them.
The suggestion therefore is that simulators download group-permissions on an as-needed basis depending on where you are. So if I'm on my home land, it will download the appropriate group for that. Then if I move to other land, and am in that group, it will download that. In this way the simulator only really needs to cache a handful of groups, and simply throws away the last used chunk of data if a new one is required and the cache is full. For example; I reckon few people would wander around with more than say three groups they need to be tracked for in any given simulator, it could always cache more and simply timeout unused ones in the event that a user is constantly passing through different pieces of group-land.
This group download can even be restricted to when it's necessary, ie; if my land only restricts object-creation, then my group info is only needed if I try to create an object, so download it then, as I may not create any objects at all!
This may add short delays to some operations during peak network activity, but you're likely to have a little latency then anyway. It also means that there is no longer any need to restrict groups at all, as only the client cares about other groups, it can download the full-list separately like inventory which the user can then use to access group info/accouncements etc, and register its availability for group IMs or however that works (presumably the sim may do this at the moment, but there's no reason the client couldn't, just needs checked somewhere).
So, unlimited groups, less information needing to be tagged onto avatars to pass between sims, meaning improved border crossing. I doubt it'll fix it completely as there are likely other issues, but the less data you're sending around, the better. |
Show » |
made changes - 06/Jun/07 03:34 PM
| Field |
Original Value |
New Value |
|
Link
|
|
This issue is related to by VWR-864
[ VWR-864
]
|
made changes - 14/Jun/07 12:26 PM
|
Link
|
|
This issue Relates to MISC-64
[ MISC-64
]
|
made changes - 01/Nov/07 03:36 AM
|
Link
|
|
This issue Relates to SVC-472
[ SVC-472
]
|
made changes - 01/Nov/07 03:56 AM
|
Link
|
|
This issue Relates to MISC-208
[ MISC-208
]
|
made changes - 05/Nov/07 08:08 PM
|
Link
|
|
This issue is related to by VWR-2212
[ VWR-2212
]
|
made changes - 22/Dec/07 01:00 AM
|
Workflow
|
jira
[ 12096
]
|
jira-2007-12-21
[ 20658
]
|
made changes - 22/Dec/07 01:20 AM
|
Workflow
|
jira
[ 20658
]
|
jira-2007-12-21
[ 21662
]
|
made changes - 22/Dec/07 01:53 AM
|
Workflow
|
jira
[ 21662
]
|
jira-2007-12-21
[ 23548
]
|
made changes - 23/Dec/07 12:12 AM
|
Workflow
|
jira-2007-12-21
[ 23548
]
|
jira-2007-12-22a
[ 48192
]
|
made changes - 23/Dec/07 12:29 AM
|
Workflow
|
jira-2007-12-21
[ 48192
]
|
jira-2007-12-22a
[ 49090
]
|
made changes - 12/Aug/08 07:16 PM
|
Component/s
|
|
Groups
[ 10222
]
|
made changes - 13/Nov/08 12:02 PM
|
Workflow
|
jira-2007-12-22a
[ 49090
]
|
jira-2008-11-14
[ 80121
]
|
made changes - 13/Nov/08 04:26 PM
|
Workflow
|
jira-2008-11-14
[ 80121
]
|
jira-2008-11-14a
[ 86023
]
|
made changes - 13/Nov/08 04:39 PM
|
Workflow
|
jira-2008-11-14
[ 86023
]
|
jira-2008-11-14a
[ 89586
]
|
made changes - 13/Nov/08 04:46 PM
|
Workflow
|
jira-2008-11-14
[ 89586
]
|
jira-2008-11-14a
[ 92155
]
|
made changes - 30/Sep/09 01:32 PM
|
Affects Version/s
|
|
1.30 Server
[ 10510
]
|
|
Affects Version/s
|
|
1.27 Server
[ 10460
]
|
|
Affects Version/s
|
|
1.26 Server
[ 10420
]
|
|
Affects Version/s
|
|
1.25 Server
[ 10380
]
|
|
Affects Version/s
|
|
1.24 Server
[ 10351
]
|
|
Affects Version/s
|
|
1.23.4 Server
[ 10343
]
|
|
Affects Version/s
|
|
1.22.4 Server
[ 10340
]
|
|
Affects Version/s
|
|
1.22.3 Server
[ 10331
]
|
|
Affects Version/s
|
|
1.22.2 Server
[ 10330
]
|
|
Affects Version/s
|
|
1.22.1 Server
[ 10320
]
|
|
Affects Version/s
|
|
1.21.0 Server
[ 10310
]
|
|