SLDev-Traffic 1

devsl-traffic no 1

devsl discussions through March 2, 2007

Executable Switcher

Noting that plugins will take a while to mature and that testing new features 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, and Dale Glass noted that viewers could have a small amount of different and incompatible data, such as the modified XML menus in his own scanner.

Peekay Semyorka voiced additional concern that this would result in only one feature being available at a time, and Dale Glass emphasized that this is a temporary solution until plugins are ready.

Viewer Manifest

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

Ron 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. Ryan Williams said yes to the GPL.

LLMozLib

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.

LLJack and C++

Soft Noel posted a first drop of a plugin system that can load plugins as libraries and negotiate multiple versions of an interface. The first version is Intel Mac only, but includes work toward other architectures.

As designed, the interfaces are offered as C++ classes. 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. Others supported Argent Stonecutter's concern, and Soft Noel is reworking LLJack to use C instead of classes.

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.

Plugin Autoupdater

Tim Shephard voiced concern that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins. Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' sites be hacked. In IRC, 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 1.13.3.58390 source on Feb 24 and the 1.13.4.3 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 1.13.4.3 open source builds unusable on an Intel Mac. Others have had similar problems with the Linux build.

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

Stereoscopic Viewer

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 SLDevers. 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

Jesse Nesbitt noted that there is already a packet called ObjectExtraParams in the message template and wondered if LL were already planning such a feature. John Hurliman noted that the packet goes from the viewer to the sim, and is used for setting things like lighting and flexible parameters.

There was further discussion about whether an arbitrary named attribute system was desirable. In IRC 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:

https://lists.secondlife.com/pipermail/sldev/2007-February/000582.html

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 offered a patch for starting SL in 16 bit mode if 24 bit mode failed, however it caused Truxpin's machine to revert to software rendering. David Fries states that Linden Lab currently requires 24 bit mode, while Mesa only supports 16 bit depth. This apparently means that nVidia users will require the closed source driver for full 3D 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.