Why is this feature important to you? How would it benefit the community?

There are dozens and dozens of applications that rely on keeping data persistently or exchanging data grid-wide. For example having script settings survive the script reset or a network of scripts communicating grid-wide, e.g. a vending network or a stargate network and many others.

By now one has to use an external services as scripts loose data due reset and HTTPD servers loose their URI on region restart. Experiences are an approach to solve this problem but they have two handicaps:

First, experiences are regional. This makes them out of use, as when you give an affiliate vendor, you cannot tell the reseller to put the region into your experience in order the vendor starts working. You need gridscope experiences for this purpose but apparently they will be only released when there is a way to allow or disallow experiences in advance, without needs to touch each one separately.

Second, experiences include avatar influences, like animating or camera controls. When you want only exchange data with the experience database, you not need the influence capability. Furthermore, the fact that each experience includes this capability seems to me the reason why there are no gridscope experiences yet. This influence is the only "danger" a not blocked experience can have to avatars at any particular region.

This feature request tries to handle this.

Experience aspects

Aspects describe the capability of a particular experience. By now there are two, database aspect and avatar influence aspect:

• Database aspect: Only when an experience has this aspect, the script compiled in this experience is able to use KV database. When the experience has this aspect not, the commands LlCreateKeyValue, llReadKeyValue etc. will produce a script error.

• Influence aspect: Only when an experience has this aspect, the script compiled in this experience can call LlRequestExperiencePermissions. When the experience has this aspect not, calling LlRequestExperiencePermissions fails silently. Without having an experience permission requested a script can not influence the avatars in experienced way.

  However if an experience has the influence aspect or not, scripts compiled for this experience stil can call the regular llRequestPermissions function and e.g. animate an avatar when permission is given.

  An experience must have one of the aspects or both. The experiences created already are full experiences having both aspects active. Creating new experiences will have the aspect selection involved.

  An experience can change the aspects in the future but then it may loose the experience permissions or the default gridscope status.

  Pure database experiences

  When an experience has the database aspect but not influence aspect, than it is a pure database experience. This experience cannot request experience permissions, it will not appear in the experience floater of residents.

  When a script is compiled for the experience, all experience actions the script will do, happen transparent for the residents, between the script and SL servers. The script has no "danger" to influence an avatar uncontrolled.

  This are the reasons why pure database experiences can be gridscope by default.

  This is actually the solution for the need of having grid-wide accessible data storage I have introduced above.

  Pure influence experiences

  When an experience has only avatar influence aspect but no database aspect, it is a pure influence experience. Scripts compiled for this experience have no access to a KVP database, thus they will generate no data except storing the experience permissions they have requested.

  The experience will appear on the experience floater of the residents. I think there should be no way for a resident to tell if an experience has the database aspect or not.

  However, a pure influence experience is a light-weight experience and if there is a charge for the experiences, pure influence experiences would be cheaper than full experiences because of producing less data load or there can be also an other reason why a pure influence experience is benefical in any special situation.

  Experience parcel settings.

  Having the experience aspects, it makes also possible to have better control about what (gridscope) experiences are allowed on the parcel: You simply allow every aspect of the experiences separately. The mask will look like this:

• Database aspect: All gridscope, Regionscope experiences only.

• Influence aspect: All gridscope, Regionscope experiences only.

  This way you can e.g. allow only gridscope database experiences in advance and allow this way the gridwide script communication to and from your parcel but disallow gridscope experiences that influence the avatars.

  In advance means you can set the setting this way and have no needs to disallow every gridscope experience an occasional visitor may bring with their script.

{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-03-02T13:35:29.708-0600',
  'How would you like the feature to work?': 'a',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'b',
}