[Opensim-dev] moving away from grid vs. standalone

[Michael Cortez]

Let me just throw another view point out there.

As some of you may know I am currently working on a groups 
implementation.  I do not expect it to be "the" groups implementation, 
and I fully expect it to be replaced later -- but it is _a_ groups 
implementation.

One of the things I've been trying to strive for is for it to be as 
loosely coupled to OpenSim as possible, so that as we move forward the 
server component of groups can support all variations of OpenSim as well 
as direct access from viewers, web browsers and even from regions in 
multiple grids.

Now that I've started to actively work on things like internal security 
to groups and verifying agents prior to committing changes to the 
group's data-store -- I've started to run into problems due to us having 
multiple "modes".

Things that should be simple like providing the group server with an 
AgentID, Session and a url to verify that against, has to get convoluted 
with checks to see if it's a local user or a foreign user because you 
have to get the user service url from two different places.  Local users 
have a user service, foreign users have a user service, therefore every 
UserProfile should have a reference to their user service.  However it 
looks like this isn't currently true, because it wasn't originally 
conceived that different users would need to carry around different user 
service urls.

The code also has each of these service urls {user, asset, inventory, 
etc} -- hard coded -- so you have to modify the UserProfile class to add 
new ones, rather then each user having a service lookup mechanism {even 
just a simple Dictionary<ServiceName, URL> would be quite a bit better 
for supporting new user services that are perhaps added via region 
modules rather then in the core.  And currently there is absolutely no 
support for having multiple service urls for a particular service -- 
which then prevents forward looking designs that may allow an agent to 
have inventory stored on multiple servers, or be using multiple groups 
servers.

This is just the tip of the ice burg as it were -- there are numerous 
places where having separated "stand alone" vs "grid" vs "SA + HG" vs 
"grid +HG" -- has made things overly complicated.  I say, just make it 
always be "grid" -- it may be a grid that stands alone, using local 
services, and is only a single region but always a grid.  All of the 
user services should always be exposed via remotely accessible protocols 
{http/xmlrpc/rest/whatever} -- this will allow forward looking client 
designs where clients can access these services directly, as well as 
allowing new services {such as groups} to always have a known set of 
services that it can access remotely.

I highly suspect as we move forward, and we start looking at things like 
using Jabber or similar services for messaging, we will have an ever 
growing need to decouple services from the core, and make them 
accessible "remotely" -- even if it's just another process on the same 
machine, or within the same private network.

I dunno if that helps or not, but just my 2 cents -- and if it wasn't 
clear I'm +1 on collapsing the "standalone" vs "grid" -- so that it is 
always grid, perhaps with a switch that allows direct in process access 
to services {if available}

--
Michael Cortez