SL projects updates week 4 (2): server, viewer, webkit

Maestro Linden's disco-themed Server Beta meeting venue (stock)
Maestro Linden’s disco-themed Server Beta meeting venue (stock)

Server Deployments Week 4 Recap

As always, please refer to the deployment thread in the forums for the very latest news.

Server Deployments in Week 5

Details on the deployments for week 5 (commencing Monday January 27th) have yet to be finalised. However, it appears there will be a new server maintenance projects targeted at the RC channel, which Maestro Linden outlined during the Server Beta meeting on Thursday January 23rd:

We’ll have another small maintenance project going out next week which includes another crash fix and a fix to llModifyLand(), [where] the bug is that calling it in a child prim modifies the wrong land.

For example, if a child prim is offset by <8,4,0> from the root prim, then calling that function in the child prim will try to modify the terrain at <8,4,0>  of the region,  which may or may not work depending on who owns the parcel.

The fix is to make it modify the land underneath the child prim (which of course follows the same permissions rules – you can only modify land owned by the script owner.

Unless another project pops-up in the interim, it is likely this update will be deployed to all three RC channels in week 5.

SL Viewer Updates

A new Maintenance RC viewer appeared in the release channel on Thursday January 23rd. Version includes some 43 MAINT related fixes and updates, as listed in the release notes.

All other viewer RC, project and the release viewer remain unchanged, per my notes in part one of this week’s report.

HTTP Work – Monty Linden

Monty attended the Server Beta meeting to provide some more information on the HTTP project work.

“Basically, my hope is to move http operations to a domain where ping time has far less impact on experience as well as just doing HTTP better,” he said of the current work, the benefits of which are currently in an RC viewer – version “And that is happening.” (See Monty’s blog post on the subject.)

HTTP Pipelining

This work was slightly sidetracked as Monty got involved in issues around third-party libraries (see below). However, pipelining is seen as the first major step that will give the Lab some ping time independence, and it is likely that it will involve some server-side work.

“The server work will be small, a change in fairness policies,” Monty stated by way of a broad explanation, “and throttle implementation but that isn’t set in stone yet.”

Third-party Library Work

The work on the third-party libraries has been covered in a number of recent HTTP project updates. These are the used in building the SL viewer, including zlib, libpng, openssl, ares, libcurl, boost and SDL, all of which Monty has been rebuilding, as well as “tweaking” colladadom, openjpeg, Google-mock and llqtwebkit.

The aim is to ensure that these libraries are up-to-date, and are probably managed and maintained and correctly used throughout the viewer build process.  This work should help, longer-term with any move by the Lab to 64-bit viewer builds, and should be of benefit to those TPVs already building 64-bit variants of their viewers.

Webkit Woes

Webkit is a third-party library used within the viewer for a number of tasks. For example,  it powers the built-in web browser, and is used to display profiles (unless you’re using a viewer supporting legacy profiles). It is also used with like Media on a Prim (MOAP) and many in-world televisions.

There have been an increasing number of issues with Webkit. The libraries used within SL are out-of-date, for example, something which has caused the Lab and TPVs a considerable amount of pain.

More recently,  users have been encountering issues when trying to view YouTube videos via the built-in browser or MOAP, reporting that they are seeing an error message informing them that  “You’re using Safari browser on Windows that we’ll soon stop supporting” (BUG-4763 and FIRE-12642), or reporting they have sound but no video (FIRE-11057). An Adobe engineer has commented on the latter Firestorm JIRA, explaining the problem, and has indicated he has contacted Linden Lab as well.

It’s unclear as to how this matter will be handled going forward. While Monty has prodded at Webkit as a part of his additional work on third-party libraries, and overall fix may not be that straightforward. As such, it appears the way forward in dealing with the video issues is currently unclear.