[Opensim-dev] OSGrid <-> UCIGrid

Thu Oct 30 18:29:43 UTC 2008

No no no, there's no dependency on OSGrid's user server. I can TP to 
OSGrid coming from my account on the UCIGrid too. I just used OSGrid as 
one of the peers, because well... it's there, it's open for anyone to 
experiment, and most of you have OSGrid accounts, as opposed to UCIGrid 
accounts.
The hyperlinking is generic already.

Chris Hart wrote:
> While, admittedly, I've not looked at the code details yet, the phrase
> "Anyone with an OSGrid account can travel back & forth" leads me to
> assume this means you have to use the OSGrid user server as part of any
> participating grid configuration. This is fair enough, but any
> interoperability solution needs to be as configurable and scalable as
> possible. 
>
> It's certainly a great experience to teleport that way, and this is a
> fabulous proof of concept, but a reliance on a central user server
> pushes it out of use for many. My feeling is for optional module here
> too for now.
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin
> Clark-Casey
> Sent: 30 October 2008 18:06
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid
>
> Charles Krinke wrote:
>   
>> Dear Crista:
>>
>> I have no problem supporting and committing patches to core from your 
>> efforts. Please move forward as you see appropriate.
>>
>>     
>
> Strong -1 on committing this code directly to core at this stage.
>
> Charles, I strongly believe it would be better for us to see this mature
> a little as an external module first, rather 
> than committing code directly to core.  Please could we hold off at
> least until the code has reached some level of 
> maturity, at which point we can have a discussion about what we want to
> do.
>
> This would be the same policy that we've tried to establish in the wake
> of other architectural changes (such as secure 
> inventory) which really need some review and consideration first
>
> There is also an argument that such modules should eventually be outside
> the core anyway.  The OGP modules we have are 
> in there because our region infrastructure module isn't advanced enough
> to make it easy to host these outside of core. 
> This is something we should address (either having some protocol modules
> in or having them all out).
>
> That's not to say that this isn't very interesting work, Cristina.  Does
> the code fit into the module structure?
>
> I had thoughts along similar lines for distributed grids.
>
> http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without
> -big-grids/
>
> but I never actually implemented anything = so fair do's to Cristina.
> Also, my thoughts were to conduct everything 
> client side.
>
> The problem does some with asset and inventory and routing this
> information around.  My thinking was that it would be 
> better if the client fetch this information directly rather than via the
> sim, but this would require extensive (and 
> probably difficult) client changes.
>
>   
>> Charles
>>
>>
>> ----- Original Message ----
>> From: Cristina Videira Lopes <lopes at ics.uci.edu>
>> To: opensim-dev at lists.berlios.de
>> Sent: Thursday, October 30, 2008 9:19:28 AM
>> Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid
>>
>> Mircea Filipescu wrote:
>>     
>>> Me too. I would be curious to ask two questions now, one of them 
>>> related to that. First question is, how do you set that up on your
>>>       
> own 
>   
>>> opensim so far? Is the inter-grid teleporting system in the core yet 
>>> or just an experimental separate application? Will there be a way
>>>       
> from 
>   
>>> opensim.ini to do that experimentally soon?
>>>       
>> It's not in the core. It would be great if it makes it there :-) It
>>     
> will 
>   
>> be really easy to merge.
>> Since the architecture of OpenSim is so good (I've said this many
>>     
> times 
>   
>> before!), the extension I made is really modular and simple. The only 
>> weirdness is having to subclass OpenSim.cs <http://OpenSim.cs>, so
>>     
> that 
>   
>> I can instantiate the hypergrid comms instead of the default comms.
>>
>>     
>>> My second question is something on longer term related to the 
>>> technical part; I'm curious what will be done with the assets in this
>>>       
>
>   
>>> situation and with fetching them, and here I mean how one can sit on 
>>> one grid and use assets and inventory from both that grid and another
>>>       
>
>   
>>> one. There are two problems here; First of them (smallest one) is the
>>>       
>
>   
>>> possibility of UUID conflicts. Lets say for example that someone 
>>> uploads a texture on OSGrid and uses it in their inventory. Now they 
>>> cross-grid TP to the LL grid, and in order for stuff to work
>>>       
> correctly 
>   
>>> both the OSGrid asset server and LL grid asset server must be used. 
>>> However, if the UUID of that texture he just uploaded on OSGrid is
>>>       
> the 
>   
>>> same as the UUID of another texture / asset already on the LL grid, 
>>> there will be a UUID conflict.
>>>       
>> For this issue, I'm relying on probabilities & statistics! I hope the 
>> math delivers :-)
>> But I confess I feel a bit nervous about this too. I would feel a lot 
>> more comfortable if UUIDs would be suffixed with a domain name, or if 
>> they encoded domain names, so that ambiguity would be impossible, not 
>> just improbable.
>>
>>     
>>> Second problem as the devs have been discussing is that the SL client
>>>       
>
>   
>>> can only support one asset server at a time. So if you go into
>>>       
> another 
>   
>>> grid like that normally you must have both the assets of the grid you
>>>       
>
>   
>>> come from and the ones of the grid you go to at the same time. So
>>>       
> yeah 
>   
>>> I was curious if anything is intended or known about these problems
>>>       
> so 
>   
>>> far... one way or another I guess they will be gotten through so
>>>       
> yeah.
>   
>>  >From what I hear, there is a distributed asset server in the making.
>>     
>
>   
>> We'll have to exchange some ideas.
>> It's too bad that the client is so attached to the one-mamma model. We
>>     
>
>   
>> need to constantly trick it on the server side.
>>
>>
>>
>>     
> ------------------------------------------------------------------------
>   
>> _______________________________________________
>> 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/20081030/56716c46/attachment-0001.html>