sldev-traffic no 1
sldev discussions through March 2, 2007
Noting that plugins will take a while to mature and that distributing new features for testing was desirable, Dale Glass proposed a system for selecting among multiple viewer versions at launch time:
Since most people don't have nearly the bandwidth capabilities of LL, making things compact is important. For that reason, alternative clients will be distributed in say, NSIS packages, but include only the changed files, as well as some metadata. The metadata indicates among other things on which LL release it's based. Switcher will assemble a working SL install based on the original files and the modifications from the installed package, then run that. If the third party client is based on a SL version that's not installed (say, firstlook based and user is running the stable client), then the switcher will try to automatically download the official version to use as a base.
Peekay Semyorka wondered at why a user couldn't install multiple EXEs in the viewer directory. Dale Glass noted that viewers may have different and incompatible data, such as the modified XML menus in his own scanner.
Dale Glass emphasized that this is a temporary solution until plugins are ready.
In the Executable Switcher thread, Ryan Williams noted that he would introduce a Python-based installer packaging script in the next release, which came with the beta release this week. The documentation is here: https://wiki.secondlife.com/wiki/Viewer_Manifest
Rob Lanphier invited feedback on Ryan Williams' script, noting that engaging Lindens productively (Ryan Williams is a Linden) is a good way to encourage Lindens to reciprocate.
Christian Westbrook inquired about whether the packaging script would be GPL'd, noting current work in deploying OpenSL with the NullSoft packaging system. Yes on the GPL.
Tofu Linden announced the upload of LLMozLib/uBrowser
LLMozLib is a library (and set of Mozilla patches) written by Callum and others which we use to create our embedded Mozilla widgets inside the Second Life viewer (for web profiles, F1 Help, and the login screen currently) with a simplified API. It does not depend upon the Second Life source and can be used in your own programs. For more info about LLMozLib and uBrowser, see http://ubrowser.com/
Linux users had some remaining trouble building Second Life with Mozilla enabled, and Signore Iredell posted instructions for building without browser support: https://lists.secondlife.com/pipermail/sldev/2007-February/000532.html
Tofu Linden noted that he had committed a change to make disabling LLMozLib easier, and that it should reach the open source release soon.
C++ bindings Prototype versus C
Tim Shephard posted a C++ prototype which proved that it was possible to develop a plugin API which interfaced via C++ and inheritance. However, the issues he ran into were that you would need to build with the same compiler (both client and plugin) in order to develop compatible binaries. This was a significant non starter.
He also discussed the NPAPI API as a simple model for plugins.
C++ motivated Plugin Bindings
Soft Noel posted C++ motivated bindings that could be used as a plugin prototype. It can load plugins as libraries and negotiate multiple versions of an interface for later compatibility. The first version is Intel Mac only, but includes work toward other architectures.
The significant concern as pointed out by Tim Shephard in an earlier posting as mentioned above, is that C++ has significant Application Binary Issues on the Windows platform. (Microsoft has not guaranteed that they will support the C++ ABI from one release to the next (in fact, it changed in VS2003 -> VS2005)). This will make it difficult to support people who build their plugins with a different compiler than what Linden Lab is using.
Argent Stonecutter suggested that the bindings should be as language-neutral as possible, noting that targeting C was targeting the lowest common denominator of all languages. Soft Noel is reworking the posted system to offer a C interface instead of C++. Argent Stonecutter voiced concern about the anonymous pointers C would introduce in the plugin API and referenced an older thread. In that thread, he laid out one scheme for encoding plugin parameter formats and described the behavior plugins would follow in validating such a plugin interface. Ryan Williams suggested that the already existent LLSD would work for a plugin interface with this design and noted likely similarity between a plugin API and the messaging system.
Keep It Simple
Soft Noel suggested the ability for plugins to unload on request from a sim, should a plugin malfunction and create problems for the grid. There was much discussion about the non-desirability of such a feature, and Kelly Washington reiterated Rob Lanphier's call to keep things simple up front. Rob Lanphier linked to http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html and Kelly Washington wrote:
There will have to be a line drawn somewhere between what can be a plugin and what requires a separate client or re-compile. This line does not need to be fixed in stone at the creation of the plugin system. In fact the best approach may be to start conservatively with very little on the plugin side. This would allow the system to get out, get tested, get used and get refined quicker than building an all-encompassing plugin system from the start. ... what is the minimal needed to create a plugin system that can at least make some useful plugins? My guess is the following: - create a floater, be able to populate and update data in the floater. By this I just mean set text, set images, add/remove items from scroll lists. - add UI to bring up the floater. As a first pass even just a 'plugins' menu with a menu item for each loaded plug in. - access to specific internal data - ie the list of visible avatars, region name, current location etc Now that won't let you create just any plugin, it won't even let you create most plugins (I'm sure everyone noticed there is nothing about handling messages at all), but that is my guess as to the minimal needed by a plugin.
Soft Noel expressed concern that autoupdating plugins would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.
Two Source Releases
Rob Lanphier announced the release of the First Look 22.214.171.124390 source on Feb 24 and the 126.96.36.199 viewer beta on Feb 28: https://wiki.secondlife.com/wiki/Source_downloads
Soft Noel noted build problems on the Mac, filing several bug reports and workarounds, however a texture bug continues to make 188.8.131.52 open source builds unusable on an Intel Mac. Others reported similar problems with the Linux build on SLDev and #opensl.
Second Life viewer packaged for Fedora
Callum Lerwick announced an RPM-packaged viewer for Second Life, including library dependencies. He indicated that he had found another user doing duplicate work and suggested they had some merging to do. Packages are here: http://www.haxxed.com/rpms/secondlife/
Lip Sync and Gesture Motions
One plugin feature discussed was lip sync and gesture motions. Phoenix Linden wrote:
Just so everyone knows, we are already working on lip and gesture motions for the avatar. This is no promise of functionality or when it will be available, but it is in the pipeline and under active development.
Later in the week, Mike Monkowski noted a C|Net article regarding Linden Lab's announcement of Vivox voice support: http://news.com.com/Integrated+voice+coming+to+Second+Life/2100-1043_3-6162410.html?tag=nefd.top
Eric Maslowski noted that the University of Michigan 3D lab was working on a stereoscopic 3D viewer: http://um3d.dc.umich.edu/
Many of the questions in his announcement remained unanswered: https://lists.secondlife.com/pipermail/sldev/2007-February/000612.html
Agni, Aditi, and Uma
Dale Glass inquired about the grids available for Viewer developers. Joshua Bell replied, listing the three grids as Agni (live grid), Aditi (beta) and Uma (open source developers). Fuller details were included in Joshua Bell's response: https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html
LSL Instantiated Prim Metadata
There has been a continuing discussion about the desirability of a custom data field that LSL could set on prims, and which Viewer developers could use for representing features not yet implemented on the server. Jason Giglio summarized the feature with an example use: https://lists.secondlife.com/pipermail/sldev/2007-February/000644.html
The original Wiki proposal is here: https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL
There was further discussion about whether an arbitrary named attribute system was desirable. In #opensl discussions it was noted that named parameters could already be set when communicating with the sim, but nobody voiced any guarantee that the data would persist, or suggested that this data could be set or directly accessed from LSL.
LSL to Viewer Communications
Initially mentioned in the prior thread, Dale Glass mentioned a different system that allowed dynamic communication between a custom viewer and LSL. His details and a pointer to the Viewer source patch are laid out in his message:
Unit Testing Feedback Requested
Gaurav Sharma requested feedback on what parts of the viewer should be covered by unit testing. Rob Lanphier noted that Gaurav Sharma was working for Adroit, which had been hired for this task. John Hurliman suggested that the LLJoint class has been problematc, but there has been little other relevant feedback. Gaurav Sharma updated the patch with a second version later in the week. That version is here: http://lists.secondlife.com/pipermail/sldev/attachments/20070302/d8809402/unittest-2-0001.obj
Gaurav Sharma's repeated request for unit test suggestions is here: https://lists.secondlife.com/pipermail/sldev/2007-March/000695.html
Linux Viewers and 3D Acceleration
Truxpin was having difficulty making Second Life run on his machine using open source nVidia drivers. David Fries states that Linden Lab currently requires a 24 bit depth buffer, while Mesa only supports 16 bit depth. David Fries (SpacedOut Frye) offered a patch that would request an OpenGL context with a 16 bit depth buffer if the 24 bit depth buffer request failed.
Truxpin posted an e-mail including glxinfo which showed,
direct rendering: No server glx vendor string: SGI
Indicating he only had software OpenGL rendering available. The patch allowed the Second Life viewer to run with a 0.7 frame rate which also indicated software rendering.
Truxpin later posted (off list) that he was able to get the nVidia driver installed and running at about the same speed under Linux as Windows on that computer.
nVidia users currently require the closed source driver for 3D OpenGL acceleration.
Linden Lab and Open Source
Christian Westbrook stated that Linden Lab had not yet completely accepted open source development. Rob Lanphier posted a response detailing the extent of Linden Lab's contributions and some of the remaining legal and business hurdles Linden Lab is working to move out of the way.
Rob Lanphier repeats emphasis on the necessity for list contributors to sign contributor agreements in order to free Linden Lab employees to more directly interact with SLDev members.
Plugin Source Licensing
SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.
OpenJPEG Patch Not Merged
Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-184.108.40.206 on Intel Mac. She disabled jpeg decoding to continue to make progress. David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123, which was first posted February 11th, as well as a prior patch in VWR-94. David Fries again asked why the fix hasn't made it into the source code release.