SLDev-Traffic 1

Open Source Portal > Communicate > SLDev > SLDev Traffic

sldev-traffic no 1

sldev discussions through March 2, 2007

Executable Switcher

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.

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

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.

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.

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.

Plugin Autoupdater

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

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 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:

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