[Opensim-dev] Changing GetRegions(uint, uint, uint, uint) in GridManager

Cristina Videira Lopes lopes at ics.uci.edu
Tue Oct 28 14:35:25 UTC 2008


Please send a warning when you stop doing that in the core, because the 
hypergrid extension I'm doing is heavily influenced by this SL encoding 
hack. I don't need the hack for the hypergrid to work; in fact that 
encoding for region handles is the ultimate manifestation of the 
centralized architecture that the hypergrid is departing from. But in 
practice, when the region handles don't encode the grid position 
anymore, I'll need to change my code so that I can play the grid game 
with the viewer.


Stefan Andersson wrote:
> Generally, we've been trying to move away from the region handle being 
> calculated from x/y in core, as that is an heavily sl-centric 
> assumption. It's always a bad idea to code information (like coding 
> x/y into a handle) into handles and identifiers, as I would say this 
> incident is an good example of. (sooner or later, somebody wants to 
> implement something using another handle for the same information)
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>  
> Join the 3d web revolution : http://tribalnet.se/
>  
>
>
>
> ------------------------------------------------------------------------
>
> > Date: Tue, 28 Oct 2008 16:56:31 +0900
> > From: mmazur at gmail.com
> > To: opensim-dev at lists.berlios.de
> > Subject: [Opensim-dev] Changing GetRegions(uint, uint, uint, uint) 
> in GridManager
> >
> > Hi,
> >
> > In OpenSim/Grid/GridServer/GridManager.cs there is a method with the
> > following signature:
> >
> > Dictionary<ulong, RegionProfileData> GetRegions(uint, uint, uint, uint)
> >
> > This method grabs all the regions currently in the regions table, and
> > puts them in a dictionary with the region handle as the key. It's
> > invoked in GetSimNeighboursData() and XmlRpcMapBlockMethod().
> >
> > I would like to modify this method to have the following signature:
> >
> > List<RegionProfileData> GetRegions(uint, uint, uint, uint)
> >
> > Note there is another method very similar already in GridManager:
> >
> > List<RegionProfileData> GetRegions(string, int)
> >
> > I don't immediately see any place that the region handle is required.
> > The dictionary is iterated over, the data from each region extracted
> > and passed on.
> >
> > Why is the region handle required? It's calculated from the region's
> > coordinates, so maybe it's used to uniquely identify a region? In that
> > case, could the UUID be used instead?
> >
> > The reason I want to do this is that for our load balancing application
> > we have multiple entries in the regions table for the same region;
> > different IPs and URIs for the same coordinates and hence same region
> > handle. The way the method is currently implemented, only one regions
> > table entry for each set of coordinates is returned.
> >
> > Please find the proposed diff below. Am I introducing any bugs? Is there
> > a better way to do this?
> >
> > If nobody has any issues with this, I'd like to check this in.
> >
> > Thanks,
> > Mike
> >
> >
> > @@ -165,19 +165,15 @@ namespace OpenSim.Grid.GridServer
> > return null;
> > }
> >
> > - public Dictionary<ulong, RegionProfileData> GetRegions(uint xmin, 
> uint ymin, uint xmax, uint ymax)
> > + public List<RegionProfileData> GetRegions(uint xmin, uint ymin, 
> uint xmax, uint ymax)
> > {
> > - Dictionary<ulong, RegionProfileData> regions = new 
> Dictionary<ulong, RegionProfileData>();
> > + List<RegionProfileData> regions = new List<RegionProfileData>();
> >
> > foreach (IGridDataPlugin plugin in _plugins)
> > {
> > try
> > {
> > - RegionProfileData[] neighbours = plugin.GetProfilesInRange(xmin, 
> ymin, xmax, ymax);
> > - foreach (RegionProfileData neighbour in neighbours)
> > - {
> > - regions[neighbour.regionHandle] = neighbour;
> > - }
> > + regions.AddRange(plugin.GetProfilesInRange(xmin, ymin, xmax, ymax));
> > }
> > catch
> > {
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081028/a73d678b/attachment-0001.html>


More information about the Opensim-dev mailing list