[Opensim-dev] SimulatorExtraFeatures Service

[James Hughes]

On Thu, 2014-07-31 at 01:06 +0100, Justin Clark-Casey wrote:
> Hi BlueWall,
> 
> I see you added this service to master today which appears to allow simulators to fetch 'extra' information about 
> OpenSimulator features at runtime [1].  I have a number of questions/points.
> 
> 1.  Can't this be part of GridInfo?  Why do we need another service for this?
> 

Gridinfo, while it does allow for the setting of an arbitrary set of
key-value pairs, is for sending information the viewer needs before the
user authenticates with a grid. With the advent of V2/V3 viewers, we
must send information for the viewer to find our map and search
services, else we see the SecondLife Grid services. So, in coordination
with third party viewer developers we added support to pass these needed
parameters upon login to a grid in the login response.

We added the SimulatorFeaturesModule, 6/13/2011 to support the addition
of mesh objects on the grid. Again, coordinating with third party viewer
developers, support was added on 7/31/2013 for a key-pair value called
OpenSimExtras to be sent within the simulator features. The reason for
this is because the user doesn't authenticate with a foreign grid
service when teleporting via HG and recieves no new login response form
the grid. They are launched at a region in a foreign grid, much like
teleporting within their home grid. Unless these parameters are
dynamically set in the viewer, the user will see the services provided
by their home grid, just like we saw SecondLife map and search services
in the V2/3 viewers before support of the ExtraFeatures. So, we have
been using this capability since 7/31/2013, and saw the addition of an
event on 2/14/2014 to allow various modules to set their own
OpenSimExtra parameters. The destination guide url was added to the
login response on 5/19/2013 in cooperation with Firestorm developers.
But, as all other urls supplied in the login response, the home grid
services will be shown in the viewer without dynamic refreshing of the
parameters to reflect the values of the visited grid.


> 2.  Why is the Robust side config named [SimulatorExtraFeatures]?  This makes it a pain to get a uniform config story 
> for standalone as well as grid.  Can't it also be [SimulatorFeatures] so that standalone doesn't need another seemingly 
> identical section if it needs to get this config?
> 

The Robust side section is [GridExtraFeatures]. 



> 3.  What is the purpose of the region_override config value?  If regions did want different values for extra features 
> then it would be trivial for them to workaround this.  If these really do need to be unique to the grid, then I think 
> they should really be fetched by the viewer directly from the service and not via the SimulatorFeatures capability, as 
> many of these are not really simulator features but grid-wide.
> 

I know it can be easily defeated at this point, or the owner of the
region might not set the url. However all of these parameters have been
100% controlled (or not) by the region for a year. At this point we have
a method to push working default values out to the regions if the url is
pointed at the GridExtraFeaturesService.

The SimulatorFeaturesModule has been functioning in the capacity of
refreshing these values with valid information for Hypergrid visitors
for at least one year. If it is possible for the viewer to get these
directly from a service, then why have we been doing this, instead, with
the SimulatorFeaturesModule for a year?