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

[Matthew Dowd]

> The implementations (such as virtualization) *are* irrelevant.
Well, maybe "virtualization" isn't the right word (or rather is overloaded).
 
What I'm talking about are things such as the following:
 
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.
 
So a future SL architecture may have those components (or similar or a finer level of granularity) as truely seperate components which could all sit on the same physical machine or could be sitting on different machines. Indeed they could move according to load i.e. all start on the same machine for a quiet empty sim, but transparently migrate to different machines as the sim gets busier.
 
Now, I would have said a discussion of how the sim code could be seperated into components, how to ensure those components can efficiently and reliable communicate with each other in a manner which makes it transparent whether they are on the same physical machine or not etc. *is* in scope of a discussion about future scalable architectures for SL but not of particular relevance to interoperating different VWs (whether those VW are based on SL code or other code).
 
Similarly there have been discussions about making presence processing more avatar centric rather than sim centric - those likewise are more pertinent to future SL architectures that future interoperable VW standards.
 
A format for sending prim data over the wire may also differ depending on the application - for sending prims between sim servers and the client, and possibly even between sim servers within the same VW, you what something which is both descriptive enough but also efficient both in transfer time and rendering time. For transfering objects between virtual worlds, you probably want a format which is much richer in its expressive powers (i.e. so that it can express the types of objects which can be created in either world), but probably aren't so bothered about efficiency of transfer time (as there may be additional overhead parsing the object into the closest approximation to the original that the particular implementation can handle anyway).
 
Matthew
_________________________________________________________________
100’s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071026/9a701822/attachment.htm