[Opensim-dev] SimulatorExtraFeatures Service

[Justin Clark-Casey]

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?

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc