I like the idea of being able to override the URI at the region level. That way a region or group of regions which offers a integrated experience could use the destination guide as a means for users to navigate the experience.
On Fri, Aug 1, 2014 at 12:46 PM, James Hughes <[email protected]> wrote: > On Fri, 2014-08-01 at 20:10 +0100, Justin Clark-Casey wrote: > > On 01/08/14 04:21, James Hughes wrote: > > > 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. > > > > My initial thought was that the viewer could make a call to GridInfo on > entering the foreign region. > > > > On reflection, I see that this would require that destination guide, > search, etc. URLs are always visible to the public. > > Private grids with Hypergrid disabled may not want this. At least > supplying them in SimulatorFeatures does not expose > > them to the public. If the grid did want these seen publicly then it > would supply them via the login URL (or simply via > > the web). > > > > However, if we follow this line of reasoning, then the GridExtraFeatures > service should be running on the private > > service port (by default 8003), not the public one as you currently have > it. What is your opinion on this? > > > > Even then, I'm guessing that the destination guide cannot have any > authentication requirement so that the viewer on a > > private grid can access it. Or is this where openID (?) could come into > play? > > > > > > > > > > >> 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]. > > > > My mistake. Nonetheless, I get nervous when config sections have > different names in simulators and robust since this is > > not normal practice (e.g. [AssetService], [InventoryService], > [GridUserService], etc.). However, I guess in this case, > > [SimulatorFeatures] is a simulator thing and [GridExtraFeatures] is a > service thing. But it might be more consistent if > > [GridExtraFeatures] was instead [SimulatorFeaturesService], as the > latter name would make it obviously related to > > [SimulatorFeatures]. What do you think? > > > > > > > > > > > > > >> 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. > > > > I still don't agree with this. You can never avoid the user 'defeating' > such a mechanism. I think it should simply be > > that if the user has a URI set, then the settings from that are used > unless the user has local settings which will > > override them. If the user doesn't want to override then they choose to > comment out or remove their own settings. > > > > > > > > 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? > > > > To be honest, my concern was more about a new service popping up (which > happens rarely) than the existing > > SimulatorFeatures mechanism. Nonetheless, I think all design decisions > (including mine) should always be open for > > critical assessment. > > > > If this is experimental work which can be changed then I don't have any > problem with an evolving implementation until > > it's signalled as baked. What I really want to avoid is initial code > going into master against which there is then a > > mighty outcry against ever changing because it has reached some viewer > implementations. Do you agree on this point? > > Can we continue to evolve this solution in response to critical feedback > even if this is disruptive where necessary? > > > > The main thrust of this implementation was to get the destination guide > out along with the other OpenSimExtras while viewer developers are > willing to add support for it. So with this work, it is there and gives > them what they need to develop that support and hopefully without too > much disruption in our community. > > Now on our side, I see that, really, all of the service urls in > [GridExtraFeatures] are supported in the LoginService. And, although the > search url is supported in the module, it is missing from the > [LoginService] section. > > What I would like to do next is: > > 1) Rework the Robust.ini - add the search server url to [LoginService] > (all that is needed is to add it to the ini because we already process > the setting in the service module, it just does not have an entry in the > ini) > > 2) Depend on the existing [LoginService] settings to supply the > configuration details that will ultimately be used for the extras. > > 3) Evaluate the importance of the other [GridExtraFeatures] > configuration entries and drop non-essentials. > > a) the chat modules, probably not important > b) the AllowOverride is not too effective > c) the ExportSupported seems important > > 4) Move the functionality of the GridExtraFeaturesService to the Grid > service. The main idea behind the GridExtraFeatures servce is to provide > default values that can be counted on to be reliable for the grid so > maps, search, destination guides, etc. will work properly for all > Hypergrid users. With the current implementation, we depend on the grid > owner to set the url to the service, which is a drawback. While, the > grid service will always be there an we can depend on those k-p values > getting pushed out to the region on startup. > > 5) Remove the override from the SimulatorFeaturesModule and let the > respective region modules handle their own settings as needed. > > I think this will eliminate any configuration confusion, as it will be > transparent to users and will be more dependable to get the settings > into the region instances. What are your thoughts? > > I would also like to cleanup some (probably unused) entries in the > Robust.ini as well. These are from some work on web profiles being done > to submit patches to Linden Lab before they cut the --loginurl from the > viewer. I will send an email to the list asking if anyone depends on > them and give a couple of days. > > Thanks for the input, > BlueWall > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
