<div dir="ltr">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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 12:46 PM, James Hughes <span dir="ltr"><<a href="mailto:jamesh@bluewallgroup.com" target="_blank">jamesh@bluewallgroup.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 2014-08-01 at 20:10 +0100, Justin Clark-Casey wrote:<br>
> On 01/08/14 04:21, James Hughes wrote:<br>
> > On Thu, 2014-07-31 at 01:06 +0100, Justin Clark-Casey wrote:<br>
> >> Hi BlueWall,<br>
> >><br>
> >> I see you added this service to master today which appears to allow simulators to fetch 'extra' information about<br>
> >> OpenSimulator features at runtime [1]. I have a number of questions/points.<br>
> >><br>
> >> 1. Can't this be part of GridInfo? Why do we need another service for this?<br>
> >><br>
> ><br>
> > Gridinfo, while it does allow for the setting of an arbitrary set of<br>
> > key-value pairs, is for sending information the viewer needs before the<br>
> > user authenticates with a grid. With the advent of V2/V3 viewers, we<br>
> > must send information for the viewer to find our map and search<br>
> > services, else we see the SecondLife Grid services. So, in coordination<br>
> > with third party viewer developers we added support to pass these needed<br>
> > parameters upon login to a grid in the login response.<br>
> ><br>
> > We added the SimulatorFeaturesModule, 6/13/2011 to support the addition<br>
> > of mesh objects on the grid. Again, coordinating with third party viewer<br>
> > developers, support was added on 7/31/2013 for a key-pair value called<br>
> > OpenSimExtras to be sent within the simulator features. The reason for<br>
> > this is because the user doesn't authenticate with a foreign grid<br>
> > service when teleporting via HG and recieves no new login response form<br>
> > the grid. They are launched at a region in a foreign grid, much like<br>
> > teleporting within their home grid. Unless these parameters are<br>
> > dynamically set in the viewer, the user will see the services provided<br>
> > by their home grid, just like we saw SecondLife map and search services<br>
> > in the V2/3 viewers before support of the ExtraFeatures. So, we have<br>
> > been using this capability since 7/31/2013, and saw the addition of an<br>
> > event on 2/14/2014 to allow various modules to set their own<br>
> > OpenSimExtra parameters. The destination guide url was added to the<br>
> > login response on 5/19/2013 in cooperation with Firestorm developers.<br>
> > But, as all other urls supplied in the login response, the home grid<br>
> > services will be shown in the viewer without dynamic refreshing of the<br>
> > parameters to reflect the values of the visited grid.<br>
><br>
> My initial thought was that the viewer could make a call to GridInfo on entering the foreign region.<br>
><br>
> On reflection, I see that this would require that destination guide, search, etc. URLs are always visible to the public.<br>
> Private grids with Hypergrid disabled may not want this. At least supplying them in SimulatorFeatures does not expose<br>
> them to the public. If the grid did want these seen publicly then it would supply them via the login URL (or simply via<br>
> the web).<br>
><br>
> However, if we follow this line of reasoning, then the GridExtraFeatures service should be running on the private<br>
> service port (by default 8003), not the public one as you currently have it. What is your opinion on this?<br>
><br>
> Even then, I'm guessing that the destination guide cannot have any authentication requirement so that the viewer on a<br>
> private grid can access it. Or is this where openID (?) could come into play?<br>
><br>
> ><br>
> ><br>
> >> 2. Why is the Robust side config named [SimulatorExtraFeatures]? This makes it a pain to get a uniform config story<br>
> >> for standalone as well as grid. Can't it also be [SimulatorFeatures] so that standalone doesn't need another seemingly<br>
> >> identical section if it needs to get this config?<br>
> >><br>
> ><br>
> > The Robust side section is [GridExtraFeatures].<br>
><br>
> My mistake. Nonetheless, I get nervous when config sections have different names in simulators and robust since this is<br>
> not normal practice (e.g. [AssetService], [InventoryService], [GridUserService], etc.). However, I guess in this case,<br>
> [SimulatorFeatures] is a simulator thing and [GridExtraFeatures] is a service thing. But it might be more consistent if<br>
> [GridExtraFeatures] was instead [SimulatorFeaturesService], as the latter name would make it obviously related to<br>
> [SimulatorFeatures]. What do you think?<br>
><br>
> ><br>
> ><br>
> ><br>
> >> 3. What is the purpose of the region_override config value? If regions did want different values for extra features<br>
> >> then it would be trivial for them to workaround this. If these really do need to be unique to the grid, then I think<br>
> >> they should really be fetched by the viewer directly from the service and not via the SimulatorFeatures capability, as<br>
> >> many of these are not really simulator features but grid-wide.<br>
> >><br>
> ><br>
> > I know it can be easily defeated at this point, or the owner of the<br>
> > region might not set the url. However all of these parameters have been<br>
> > 100% controlled (or not) by the region for a year. At this point we have<br>
> > a method to push working default values out to the regions if the url is<br>
> > pointed at the GridExtraFeaturesService.<br>
><br>
> I still don't agree with this. You can never avoid the user 'defeating' such a mechanism. I think it should simply be<br>
> that if the user has a URI set, then the settings from that are used unless the user has local settings which will<br>
> override them. If the user doesn't want to override then they choose to comment out or remove their own settings.<br>
><br>
> ><br>
> > The SimulatorFeaturesModule has been functioning in the capacity of<br>
> > refreshing these values with valid information for Hypergrid visitors<br>
> > for at least one year. If it is possible for the viewer to get these<br>
> > directly from a service, then why have we been doing this, instead, with<br>
> > the SimulatorFeaturesModule for a year?<br>
><br>
> To be honest, my concern was more about a new service popping up (which happens rarely) than the existing<br>
> SimulatorFeatures mechanism. Nonetheless, I think all design decisions (including mine) should always be open for<br>
> critical assessment.<br>
><br>
> If this is experimental work which can be changed then I don't have any problem with an evolving implementation until<br>
> it's signalled as baked. What I really want to avoid is initial code going into master against which there is then a<br>
> mighty outcry against ever changing because it has reached some viewer implementations. Do you agree on this point?<br>
> Can we continue to evolve this solution in response to critical feedback even if this is disruptive where necessary?<br>
><br>
<br>
</div></div>The main thrust of this implementation was to get the destination guide<br>
out along with the other OpenSimExtras while viewer developers are<br>
willing to add support for it. So with this work, it is there and gives<br>
them what they need to develop that support and hopefully without too<br>
much disruption in our community.<br>
<br>
Now on our side, I see that, really, all of the service urls in<br>
[GridExtraFeatures] are supported in the LoginService. And, although the<br>
search url is supported in the module, it is missing from the<br>
[LoginService] section.<br>
<br>
What I would like to do next is:<br>
<br>
1) Rework the Robust.ini - add the search server url to [LoginService]<br>
(all that is needed is to add it to the ini because we already process<br>
the setting in the service module, it just does not have an entry in the<br>
ini)<br>
<br>
2) Depend on the existing [LoginService] settings to supply the<br>
configuration details that will ultimately be used for the extras.<br>
<br>
3) Evaluate the importance of the other [GridExtraFeatures]<br>
configuration entries and drop non-essentials.<br>
<br>
a) the chat modules, probably not important<br>
b) the AllowOverride is not too effective<br>
c) the ExportSupported seems important<br>
<br>
4) Move the functionality of the GridExtraFeaturesService to the Grid<br>
service. The main idea behind the GridExtraFeatures servce is to provide<br>
default values that can be counted on to be reliable for the grid so<br>
maps, search, destination guides, etc. will work properly for all<br>
Hypergrid users. With the current implementation, we depend on the grid<br>
owner to set the url to the service, which is a drawback. While, the<br>
grid service will always be there an we can depend on those k-p values<br>
getting pushed out to the region on startup.<br>
<br>
5) Remove the override from the SimulatorFeaturesModule and let the<br>
respective region modules handle their own settings as needed.<br>
<br>
I think this will eliminate any configuration confusion, as it will be<br>
transparent to users and will be more dependable to get the settings<br>
into the region instances. What are your thoughts?<br>
<br>
I would also like to cleanup some (probably unused) entries in the<br>
Robust.ini as well. These are from some work on web profiles being done<br>
to submit patches to Linden Lab before they cut the --loginurl from the<br>
viewer. I will send an email to the list asking if anyone depends on<br>
them and give a couple of days.<br>
<br>
Thanks for the input,<br>
BlueWall<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>