SLDev-Traffic 30
sldev-traffic no 30
sldev discussions through October 6, 2007
Havok 4
Sidewinder Linden announced that Havok 4 had gone beta, with more details at Havok4. There are plenty of details on this page, explaining what Havok is, how to test it, how it will be rolled out and more.
Dale Mahalko was concerned about one feature in particular, specifically the physics LOD changing during heavy load. He requested that new script events be created, allowing scripts to be notified of changes in the LOD so that devices requiring complex interaction could halt and go non-physical until performance raises the LOD once more.
Farallon Greyskin expressed concern about simulator performance, with Gigs Taggart pointing out that the beta simulators are running on older machines, which aren't as quick as the class 5 hardware.
Lawson English asked about Havok 5, and Andrew Linden noted that Linden Lab are well aware of the Havok 5 release, but that discussions between LL and the "Havok folks" had lead to the decision to standardize on Havok 4 at current.
Andrew Linden answered numerous questions and provided more details. Many testers found problems and have posted a large number of JIRAs against the beta.
Please consider testing, and remember to tag Havok 4 issues with "havok4" in the JIRA title to facilitate faster importation.
Securing Logins
Sabin Linden posted Viewer Authentication, launching multiple extensive threads. "In the past, the Second Life viewer and Second Life website have both required you to type in your name and password in order to access the grid and your account information. With Website Viewer Authentication, Linden Lab seeks to bring these two together such that you will only need to type in your name and password at one place in order to access this content. Now you'll be able to launch Second Life, securely, from the SL website."
Despite much criticality and disagreement, the threads stayed mostly civil and productive, culminating in Viewer Authentication Critique, started by Matthew Dowd and extended by many more readers. (Thank you!)
Seg Baphomet, Argent Stonecutter and Tateru Nino expressed concern that the problem being solved by the initial proposal hadn't been clearly stated, possibly leading to the broad discussion following.
Among the many, many other on-list responses,
Nicholaz Beresford strongly urged that the existing login mechanism be kept, with newer login modes being optional. Others concurred. Nicholaz did amend that the current mechanism should be enhanced by adding challenge-response authentication. It's currently a straight md5 hash of the MAC and password.
Other security models were proposed by Nicholaz, Dale Glass, Dzonatas Sol, Harold Brown and others. Among the suggestions were allowing the generation of single-use logins for use on insecure networks, single L$ transaction passwords, integration with existing password managers, feature-limited logins that might disable inventory and L$ transactions, personally selected image recognition, and SSL certificate-based validation.
Matthew Dowd wondered at whether people even want some features that a web login would enable, such as persistence. "Those with multiple accounts will actually find the persistence a pain. At the moment I can remain logged into the forums with my main account, whilst testing something via my alt. The last thing I want is to start accidently posting to the forums with the wrong account because I've just logged on to test something with an alt!" Matthew also points out that a different login mechanism may provide a false sense of security, leading to more capricious use of third-party clients.
Argent Stonecutter and others point out that introducing greater reliance on and integration with web services opens potential new holes in cross-site scripting vulnerabilities. Even Google falls prey to these.
Barney Boomslang expressed concern that the web being able to launch various clients with authentication parameters had now turned the IE exploit into a "feature."
As well, Gigs Taggart points to the existing problem of allowing very weak passwords, which he's JIRAd at WEB-314.
Readers are strongly encouraged to attend Zero Linden's office hours for live discussions.
Second Life Proxy Server
Fumikazu Iseki, of Tokyo Joho University, announced the Second Life Proxy Server:
I made Second Life Proxy program. This software is Proxy Server for Second Life on Linux. It has aimed to connect to Second Life Server from the PC in the firewall such as university.
Merits: 1. You can execute Second Life from PC with private IP address in the firewall. 2. The access control (for viewer) and specification of use port number (for proxy server) are possible. 3. Full HTTPS access is possible. 4. OpenSim is supported. Inconvenience: 1. It uncorresponds to slvoice. 2. Data cache is not supported. 3. Speed is down.
Dzonatas Sol also pointed to SLSquid Proxy, which documents work toward using squid to proxy SL.
What is AgentMovementComplete.SimData.ChannelVersion?
John Hurliman asked about AgentMovementComplete.SimData.ChannelVersion. Josh Linden explained that this was used to signal transitions between different version simulators on a heterogeneous grid. Harold Brown adds that you can experience this when crossing in and out of Havok 4 sims on the beta grid.
Building Without LLMozLib
Nicholaz Beresford is considering making a client without llmozlib support, and wondered what would be affected. The intro screen, the help, and the profiles tab were named as the only current dependencies.
Lex and Yacc Upgrades on OS X
Michael Miller did not identify the platform, but a non 10.4 version of OS X now relies on a newer version of flex and a change over to bison. This has created some build problems, which the list is working through. The JIRA is VWR-2620.
Export Prims
Jurgen Lehmann created a patch that allows exporting prim parameters, eventually suitable for reconstructing prims elsewhere, or in the viewer again. He aims to create a standard format for representing prims in XML.
John Hurliman found the existing force_export_copy function, and wondered whether the current LindenGeometry format there was formal and should be adopted. Andrew Linden noted that this appeared to be ancient cruft and shouldn't be trusted to be current.
LSL Compiler Breaking on Extended ASCII
Nicholaz Beresford received an IM from a resident using the Nicholaz edition viewer, noting that Nicholaz's viewer was handling extended ASCII strings where the official Linden viewer was not. The squared (power of two) symbol was found to be the culprit in a test script. There wasn't any follow-up.
LSL Breaking on Long Chain of else-ifs
Ingmar Hupp pointed to VWR-811, which had been marked as resolved, but still appears to be a problem. This causes a problem with a long series of else-if pairs. Phoenix Linden promised to investigate.
Thanks for readin'!