On 01/08/14 20:46, James Hughes 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?
Personally, I think that making this part of the grid service is a viable option. It only deals with regions at the moment but I don't think that a call such as get_grid_parameters is an enormous conceptual stretch. This could also carry other information such as a unique UUID for the grid, something that I've wanted recently but worked around instead.
Or, one would make a proper GridInfoService and have that implemented both GridInfo and SimulatorFeatures endpoints. To be honest, I think that GridInfo has some deficiencies at the moment. For example, osGetGridCustom() has to pull data from local simulator [GridInfo] at the moment rather than pulling it from a service (in much the same way that GridExtraFeaturesService has been implemented!). Or again, perhaps both these should be part of GridService.
Or more ambitiously, as without AllowOverride both GridInfo and SimulatorFeatures don't do anything apart from get configuration information, one could have a new GridConfiguration service that simply allows simulators to grab Robust configuration and interpret it for themselves. In the long term, that would allow one to set up a simulator or make centralized configuration changes without then having to manually change config on every simulator. Or you could still argue this could be part of GridService. Or it could just be glommed on to GridInfoService if/when someone wants to implement this.
Sorry, bit of a can of worms here. At the moment, I would personally marginally lean towards a GridInfo service with both a public connector (for GridInfo) and a private connector (for SimulatorFeatures that I still am not sure should be automatically available without a connection). This is really just an adaption of what you've already done!
However, then there's the question of how such service functions should be invoked. Recently, I've been doing quite a lot of documentation work on service calls to make it easier for external systems to integrate with OpenSimulator without having to directly manipulate the DB or extend OpenSimulator with their own code. You can see some of the results at [1].
The poor quality and inconsistency of the callable 'API' is already frustrating, though that's not really so surprising as they were thrown together for the simulator's idiosyncratic needs and this stuff can be improved with time. However, it's even worse when the call mechanisms are completely different between some services (REST, http query, XML-RPC, JSON-RPC, etc.).
A long time ago, afair there was a concensus to move to HTTP REST interfaces but this was never followed through, and to be honest I think it's a hard thing to do for some services. But one of the things that I think a '1.0' project should have is some consistency in the service interfaces. I believe that it's really important to lower the barrier for people to integrate other systems with OpenSimulator.
From your previous work I suspect that you're a big fan of JSON (and hence JSON RPC). I don't mind if that's the 'best' option but I think there would have to be agreement among core developers to use it in the future (and perhaps eventually supply JSON RPC mechanisms for all service interfaces). I don't think that we can continue to increase the diversity of service call mechanisms.
Then again, the path of least resistance right now would be to have a service interface that looks much like most of the others, where there's a METHOD HTTP query parameters and other parameters are passed in as part of that query. At least with get_grid_info and get_simulator_features (for example) this would be relatively painless.
[1] http://opensimulator.org/wiki/Services
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 .
-- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
