[Opensim-dev] SimulatorExtraFeatures Service

Fri Aug 1 19:55:06 UTC 2014

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 <jamesh at bluewallgroup.com>
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
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140801/e92965e0/attachment.html>