I would like to see SL provide the means for Agents, and Nautical Vehicles (Sailboats, Yachts, etc.) to traverse on a course between non-connected Sims, or along the shoreline boundary of the SL Mainland, by on demand instantiation of a series of Virtual Sims, which would only need to support sufficient prims for the vehicle and its occupants, along the course between a point of departure, and a destination. As a vessel, or group of vessels, vacated a SIM along the course, the VM could be brought down, and another one instantiated further ahead, with the next region's data and configuration preloaded.
Reservations could be taken via some scripted interface prior to departure, L$ could be charged as toll (deferring costs of the service), random events (weather, seas, currents, sea creatures) could be presented along the course to provide realism and adventure. Regattas and tours could be organized within the performance constraints of such virtual host instances.
Speaking of performance, I would submit that tuned paravirtualized Xen DomU instances running on a 64bit Linux DomO (a feature of Xen 3.1) on appropriate hardware, could readily handle significant load for such features. Moreover, in general, I would say that LL should consider moving from monolithic hosts, to virtualization in general, ASAP, as a means to better balance load and provide fault tolerance (live migration) of sims for maintenance, and performance optimization.
I was extremely interested in the coments made in the wiki regarding the dynamic splitting of a busy SIM onto additional server resources.
http://wiki.secondlife.com/wiki/Brainstorming (Implementation thoughts->Regions)
Under virtualization, and employing Xen's API and scripting automation, LL could dynamically add processor vcpu, and memory, to an overloaded SIM, to restore adequate performance (I.E. xm vcpu-set and xm mem-set). If not all of the hardware's cpu and memory were preallocated, and 'reserves' were kept available to bolster flagging performance in a sim, then the system would not need to scavenge vcpu and memory from underused SIMs. Additionally, heavily loaded SIMs could be migrated (live migration) as needed, and memory and vcpu adjusted, to an optimized 'best fit' between a set of servers (say within the same Datacenter and VLAN) where such were possible. SL could even data-mine upcoming events from 'Search', I.E.: Live Music Events, Popular Night Clubs at peak hours, Sporting Events, etc., and dynamically scale the performance of SIMs hosting such events, prior to their scheduled commencement, by increasing memory and vcpu and/or migrating them to hardware where such resources were available.
Vhosting opens up a great deal of opportunity for innovative, on demand, features and services, as well as gains in overall performance and reliability, at the cost of additional complexity in management. However, such complexity can be tamed by developing customized sysadmin management tools, which directly addressed SL needs, from the suite of tools provided by the Open Source Xen development community. Of course, if the financials warranted, LL could choose to purchase XenEnterprise v4, or even VMWare VI3 (for twice the price) and have most of the management tools at hand immediately.
One thing that is rather annoying at times with the current SL protocol is that a particular sim or other grid component may be listening on any arbitary port in the 13000+ range. Perhaps it is possible to simplify this to just 1 port per server type and register these ports with IANA?
Furthermore, to permit vhosting, one could do it HTTP-style and indicate per-circuit or per-message which region on that particular region host (for example) you wish to speak to.