Revision as of 19:00, 7 November 2012

Date

October 2012

Status

In progress

Proposers

• Michelle Argus
• Justin Clark-Casey (justincc)

Introduction

This may encompass many improvements to groups, but the first is to cache login information in groups to improve group IM, such that an IM isn't sent to every single user, even those offline.

A) Proposal

Please see mailing-list e-mails [1], [2] and [5]. The changes for OpenSimulator and XmlRpcGroups are in [3] and [4].

These changes send login status information and time to the groups service from the simulator. This allows an extra 'offline' parameter to be passed to GetGroupMembers to control whether all or only online members of a group are returned.

PROS:

• Only a single network call (which may be cached for a period) required on each group IM.
• Reasonably simple.
• May allow messaging across multiple OpenSimulator installations.

CONS:

• Extra calls to groups service on each login/logout.
• Groups service has to cache extra information.
• Cached information not reuseable by other services.
• Accuracy of login status is dependant on groupsettings of each simulator within a grid (multiple groups possible in open grids like OSGrid).

B) Alternatives

One alternative is for the simulator to fetch group information and then query which group members are online.

PROS:

• Groups service doesn't need to handle online status.
• One source of online status truth that cannot become inconsistent with information cached in the groups service.
• Other services can also use the same simulator-side group users online caching, though this may not be a big factor.
• Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.

CONS:

• Every group IM still requires an extra network call to GridUser services via the simulator, though this would be mitigated by short-term caching.
• Comparatively complex.
• If code external to OpenSimulator wanted to know online users for a group, it would have to call Presence service (and possibly cache information) itself rather than just being able to query the groups service.
• Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.

C) Alternatives

Similar to Alternative B, the group service requests the login status of the members from the gridservices instead of the simulator. The group service could cache members login status for a short time to reduce requests made.

PROS:

• Simulator doesn't need to handle online status.
• One source of online status truth that cannot become inconsistent with information cached in the groups service.
• Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.
• Fast data connection between grid and group server
• All grouprelated services can use the login data

CONS:

• Every group IM still requires an extra network call to GridUser services via the group service, though the results could be cached for a short period of time (e.g. 20 seconds).
• Comparatively complex.
• Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.
• Other services could reuse

D) Alternatives

4. alternative is, that the simulator only passes on the group message itself to the group server. The group server then sends the IM to all online group members.

The login status could be handled by the simulator, grid services or group service (see A, B and C).

PROS:

• Central service
• Only one request is sent to the group service.
• The simulator does not need to send messages and saves resources on the simulator side.
• The group server can be ajusted better as its sole purpose is to manage the grouprelated work.
• Spam and illigal activity can be filtered gridwide.

CONS:

• The grid management has to maintain the group server.
• Laws governing data protection and data security could be abused by gridmanagement.
• The group service requires client data to send the message to each groupmember

E) Alternatives

The login status could be handled by the grid services or group service (see B and C). The group messages can optionaly be sent by the simulator or via a "relay" service which send the message to the members. The relay service receives the group member list from the central group service. The relay service can additionaly cache data

PROS:

• Multiple relay service could be in use worldwide and minimize slow requests
• Requests to the group service is minimized due to cache of each relay service.
• Hosters of multiple regions can optimize their own relay service to their needs within their datacenter
• The simulator does not need to send messages and saves resources on the simulator side(optional).
• Each relay can offer filters for spam and illigal activity which meet local laws.
• POC for other services such as assets, presence, inventory, friendslist and many more.

CONS:

• The relay service requires client data to send the message to each groupmember
• Requires trustworthy relay hoster.

NB: The simulator could automaticaly receive the settings of the nearest trusted relay station from the grid service on simulator startup to minimize request to the central group service.

Status

The alternative approach B) is present in OpenSimulator git master as of git master 1937e5f on 2012-10-20. It can be enabled by setting

[Groups]
MessageOnlineUsersOnly = true

in OpenSim.ini (all the other groups config params need to be set and configured correctly). More details on the parameter are in the [Groups] section of OpenSimDefaults.ini. This is currently considered experimental and defaults to false.

References

[1] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011421.html

[2] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011431.html

[3] https://github.com/MAReantals/opensim

[4] https://github.com/MAReantals/flotsam

[5] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011434.html