<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
The hyperlinking is generic already.<br>
<br>
Chris Hart wrote:
<blockquote
 cite="mid:6ABFBBBFA9738E47A00F30BC3C74171C1D9FAE@kitt.CT.local"
 type="cite">
  <pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>
[<a class="moz-txt-link-freetext" href="mailto:opensim-dev-bounces@lists.berlios.de">mailto:opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Justin
Clark-Casey
Sent: 30 October 2008 18:06
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>
Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid

Charles Krinke wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Dear Crista:

I have no problem supporting and committing patches to core from your 
efforts. Please move forward as you see appropriate.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

<a class="moz-txt-link-freetext" href="http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without">http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without</a>
-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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Charles


----- Original Message ----
From: Cristina Videira Lopes <a class="moz-txt-link-rfc2396E" href="mailto:lopes@ics.uci.edu"><lopes@ics.uci.edu></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>
Sent: Thursday, October 30, 2008 9:19:28 AM
Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid

Mircea Filipescu wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->own 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">opensim so far? Is the inter-grid teleporting system in the core yet 
or just an experimental separate application? Will there be a way
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->from 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">opensim.ini to do that experimentally soon?
      </pre>
    </blockquote>
    <pre wrap="">It's not in the core. It would be great if it makes it there :-) It
    </pre>
  </blockquote>
  <pre wrap=""><!---->will 
  </pre>
  <blockquote type="cite">
    <pre wrap="">be really easy to merge.
Since the architecture of OpenSim is so good (I've said this many
    </pre>
  </blockquote>
  <pre wrap=""><!---->times 
  </pre>
  <blockquote type="cite">
    <pre wrap="">before!), the extension I made is really modular and simple. The only 
weirdness is having to subclass OpenSim.cs <a class="moz-txt-link-rfc2396E" href="http://OpenSim.cs"><http://OpenSim.cs></a>, so
    </pre>
  </blockquote>
  <pre wrap=""><!---->that 
  </pre>
  <blockquote type="cite">
    <pre wrap="">I can instantiate the hypergrid comms instead of the default comms.

    </pre>
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">one. There are two problems here; First of them (smallest one) is the
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->correctly 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->the 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">same as the UUID of another texture / asset already on the LL grid, 
there will be a UUID conflict.
      </pre>
    </blockquote>
    <pre wrap="">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.

    </pre>
    <blockquote type="cite">
      <pre wrap="">Second problem as the devs have been discussing is that the SL client
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">can only support one asset server at a time. So if you go into
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->another 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">grid like that normally you must have both the assets of the grid you
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">come from and the ones of the grid you go to at the same time. So
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->yeah 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">I was curious if anything is intended or known about these problems
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->so 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">far... one way or another I guess they will be gotten through so
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->yeah.
  </pre>
  <blockquote type="cite">
    <pre wrap=""> >From what I hear, there is a distributed asset server in the making.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">We'll have to exchange some ideas.
It's too bad that the client is so attached to the one-mamma model. We
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">need to constantly trick it on the server side.



    </pre>
  </blockquote>
  <pre wrap=""><!---->------------------------------------------------------------------------
  </pre>
  <blockquote type="cite">
    <pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>