[sldev] AWG - Scope (Future SL Architecture versus Multiworld Interoperability)

[Zha Ewry]

I don't think that anything which examines a place where we may want to
expose an interface is out of scope. While I think the major thrust of the
work is going to be defining what happens between components, we can't fully
bound those boxes, without looking at the various ways the parts inside
could reasonably be placed in various implementations. Just as Linden is
pulling out a bunch of function from the monolithic simulators today, we may
pull more function out later, if we can show how to compose reasonable
systems out of further splits.

I have posted some serious musing about the *core* functions of a region
simulator. They hang off my personal page at the moment:
https://wiki.secondlife.com/wiki/User:Zha_Ewry

Notice that scripting isn't in core functions. What one might have to do to
expose the right information to allow scripting to be offloaded. That's a
fine topic for discussion.

Notice, also, that unless virtualization, or clustering exposed things that
other components in the system would have to deal with, that's probably
beyond what we need to look at. There are a lot of very good techniques for
scaling a web hosted service (or cluster of services, which is probably the
right way to think  of region simulators) The web model fairly strongly
asserts that we only care about these details when the escape the
abstraction, and have to be accounted for. In general, clustering,  load
balancing, virtualization, should happen in ways which make them opaque to
our discussion. When they don't, we need to understand why, and account for
that.

- Zha







On 10/26/07, Matthew Dowd <matthew.dowd at hotmail.co.uk> wrote:
>
>
>
> > From: secret.argent at gmail.com
> > Subject: Re: [sldev] AWG - Scope (Future SL Architecture versus
> Multiworld Interoperability)
> > Date: Fri, 26 Oct 2007 12:10:57 -0500
> > To: sldev at lists.secondlife.com
> >
> > On 26-Oct-2007, at 11:00, Matthew Dowd wrote:
> > > the current simulator code is basically monolithic, it assumes it
> > > is all running on the same physical machine. There are however a
> > > number of different processes/engines running within that simulator
> > > code. At a first pass of granularity, we have for instance a script
> > > engine, a physics engine and an engine controlling physical
> > > location of prims and avatars.
> >
> > I think the latency would make this unworkable.
>
> Yes - there are issues around this. Latency is one, although this may not
> be a so much an issue if the components are on machines within the same
> physical LAN. The particular partitioning may not be appropriate - another
> way might be that the ground area controlled by a sim varies with the load -
> a quiet 65536sqm region may be looked after by 1 simulator but as it gets
> busier it may end up being controlled by 4 simulators each looking after a
> 16384sqm quadrant etc. (this of course assumes much smoother transfer
> between sims and better intercommunication between sim at the boundaries)
> etc.
>
> However, the point I wanted to make was not so much that these approaches
> would work in practice (there are a lot of issues/discussions to be had) -
> just that this sort of discussion should be in scope for any discussion
> about future scalable architectures for SL, even though they aren't really
> addressing isssues around opening up the SL grid to third party sims nor
> inter-VW interop.
>
> Matthew
>
> ------------------------------
> The next generation of MSN Hotmail has arrived - Windows Live Hotmail<http://www.newhotmail.co.uk>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071026/6a68e0c4/attachment-0001.htm