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? _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
