[sldev] Re: [svc] Back end features (was: New viewer released)

[Kamilion]

On 8/31/07, Dale Glass <dale at daleglass.net> wrote:
> Viewer uses handles a lot, for example object updates are sent with a handle
> and not a region key. Not sure why, compactness maybe? Though why use a 64
> bit number to keep 16 bits of data? While I expect SL will grow beyond 64K
> sims some day, more than 2^32 is something I don't think will happen any time
> soon.
>


Consider that the server/grid source will eventually make it out into
the community.

What, then, is stopping someone from running 128 simulators in xen
containers next year?

What's stopping people from having and using massive private regions?

What's stopping devices from containing a management region in them?

Picture a 2010 router with an internal simulator with all of a
modern-day's router pages each on a GeckoRenderPrim...

With 2GB of SD flash memory going for $20 today [1], it won't be odd
to see larger flash devices built into devices in the future, and
total CPU power is slowly increasing even in portable devices. More
and more portable devices will soon be multicore themselves, and power
management becomes much easier when you can control the speed or state
of individual cores, instead of scaling a single core. The PSP already
demonstrates this with it's main 333Mhz R4000 CPU and a secondary
333Mhz R4000 CPU with a different subdevice layout in the Media
Engine. The bus speed and core speed can be modified on the fly. A lot
of PSP software currently available, both homebrew and commercial,
doesn't make use of both cores. The homebrew developers are currently
working on innovative and creative uses of the second core,
StrmnNrmn's Daedalus [2] Nintendo64 emulator is a good example. It
uses the second core for dynamic recompilation of the n64's R4300, and
the RCP R4000-based coprocessor opcodes.


Now picture a network of networks full of these devices and many more like them.

Picture a smart harddrive that could expose 'folders' as simulators
full of objects.
What's to stop a simulator from becoming the next Window Manager for X?

There's many things you can do once you have access to the backend.

It's like the difference between using Geocities Pagebuilder [3] in
1995 exclusively for all your website needs, and developing a current
Ruby on Rails or PHP web application today.

This is, of course, assuming the grid doesn't fragment, or use a
link/portal-system to 'exit' to private simulators like Snow Crash
alluded to. (The metaverse club, The Black Sun is a example of such a
system, placing the exterior of the building on the 'public' grid with
the doorway as a portal to a private grid.)

The other thing is, Eventually, the grid is going to require simulator
X, Y, AND Z coordinates. Currently, as far as I know, only X and Y are
used.

Lindens, when you have a chance and feel like puttering around, add a
Z value to the region coordinates, and populate all the current
regions with a sane default value (DON'T FORGET SUBTERRANEAN REGIONS!
If you decide to use unsigned values, make sure it's a non-zero
default value!)

[1] http://www.circuitcity.com/ccd/productDetail.do?oid=134292&WT.mc_n=67&WT.mc_t=U&cm_ven=COMPARISON%20SHOPPING&cm_cat=PRICEGRABBER&cm_pla=DATAFEED-%3EPRODUCTS&cm_ite=1%20PRODUCT&cm_keycode=67
[2] http://strmnnrmn.blogspot.com/
[3] The old geocities page creator from this era was widely known as
one of the absolute worst pieces of crap ever written, garnering
geocities the nick name 'geoshitties'. One of the poorest examples of
WYSIWYG, and was limited to generating horrible looking pages. Then
again, browsers weren't very advanced then, eh? Let's try not to be
known like that in 2020 ;)