<br><br><div><span class="gmail_quote">On 9/28/07, <b class="gmail_sendername">Tleiades</b> <<a href="mailto:tleiades@hotmail.com">tleiades@hotmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> partially agreed :) the question is how much would we want to optimize and<br>> when. From my studies the calls to the backend services are only happening<br>> during the region changes - from my SL experience this is a tiny fraction

<br>> of<br>> the time spent. As such - isn't it a premature optimization in this case ?<br>Maybe a little guilty of premature optimization, but some of the flexibility<br>in the engine isn't well thought out, and will lead to pretty bad user

<br>experiences, and all the indirections makes the code difficult to undestand.</blockquote><div><br>flexibility that would lead to bad user experiences: do you have a specific example to illustrate ? <br> </div>indirections: depends on how you do it, imho. take networking - the applications do not care how their data is transmitted over the TCP connection, which in turn does not care how the to route, with IP layer not caring too much about which physical media you have. If the application layer starts to violate the layering - this is where the painful experiences start :-)

<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> I would see the backend services model (backend services not as "UGA

<br>> infra"<br>> but as a specific class which is mostly responsible for the inter-region<br>> movement) as possibly being three layers:<br><br>I like the idea 3 layer idea :-)</blockquote><div><br>:-) I just have the layer 2 omitted in my hacks, since my C# experience is not vast, and I am learning stuff as I go. Plus - running the sim is much easier without the explicit UGA. 

</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> layer 1: "my" instance. Handles all the interregion stuff for this running

<br>> instance of the sim. (since we can have multiple regions)<br>> layer 2: "this administrative domain". This is either a no-op in the case<br>> of<br>> a standalone mode (since this administrative domain == this instance), or

> OGS in the case of grid services. > layer 3: "interdomain". This handles either inter-sim or inter-grid or > inter-sim-grid operations. Agreed, local comms isn't the place to add inter-grid comms.

<br><br>> Again - I have a feeling we are doing the premature optimization here. :)<br>> The reason I thought that the interdomain teleport is an important thing,<br>> is<br>> that<br><br>Inter-grid teleport is important, I agree, but should we make it a priority

right now?</blockquote><div> I outlined the reason why I think it should be prototyped at least. There are two mutually contradictory notions at the moment: on one hand, I strongly believe the grid servers to be a single point of failure, on the other hand the absence of them would hurt since you get totally disparate sims with no connection whatsoever. Giving the users the opportunity to "link" their sims to the sims of their friends would naturally create the web, without the single point of failure.

So at least those who build stuff can show their creations to others. Arguably animations and attachments might be also quite important important  (I'd still like to be able to one day throw a live music performance on opensim - currently I'd look a bit ridiculous without the guitar and playing animation :) - and not talking about other activities which would be interesting for the wide audience and involve the attachments and animations :-) - but still after thoughts, i think "capturing the network" is more important to keep the overall momentum.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> depending on whether the above hierarchy is interesting or not, there<br>

> could<br>> be differing approaches. Maybe I misunderstood something (after all, I do<br>> remember myself being a strong advocate for doing everything via the<br>> loopback networking *only* in grid mode in the first place :) - but maybe

<br>> the discussion again goes into the direction of question of UGA - while I<br>> was talking about the very specific component, responsible for<br>> inter-region<br>> movement of agents.<br>My suggestion for using the IPC .net remoting protocol, was in order to

<br>reduce the code layers, this isn't only about performance (premature<br>optimization) but also about code complexity and maintenance. Loading the<br>4-5-6 different server modules into 4-5-6 appdomains when running a

<br>stand-alone grid, removes the worry about maintaining a local layer, meaning<br>that we can focus on grid mode, and possibly inter grid. Effectively<br>reducing into two layers, grid and inter-grid, since grid and stand-alone

</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">executes the same code, but uses different communications protocol. There is<br>

some similarity between remoting IPC and using the localhost address for communications, although I am of the impression that IPC does not touch the network stack.</blockquote><div> hm. now that I think of it... Currently we have local *or* OGS backends... if I ever succeed to produce something working, as I do not foresee rewriting the whole infra, at least in the beginning it should still work exactly like that, except there would be the "inter-domain cup" on top of it - with the selector local/grid underneath. So, yeah, looks like might be just 2 layers indeed, with the intra-domain layer having a brain to create the proper "glue" depending on whether the regions are on the same host or not...

<br><br>and yes - for the "cup" I also foresee the use of remoting. The inter-domain connections are subject to similar "identity crisis" as the avatars - so probably mutually authenticated SSL would be a need. ...later :-)

<br><br>/d<br></div></div>