A part of the Shining project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. As commented upon in the notes from the TPV/Developer meeting on July 13th, the initial focus on this project is to provide an initial texture fetch library for the viewer, together with a “wrapper” that will allow further http code enhancements to be added over time.

On Friday July 27th, Linden Lab made the initial code available within an LL project viewer (SL Alternate Viewers). The availability of the code, and LL’s plans / hopes for it were discussed during the TPV/Developer meeting also held on the 27th July. The discussion can be heard in full on the meeting recording, the key points from which have been summarised below.

During the discussion, both Oz and Monty Linden (who is leading the project) had the following to say:

The code is currently free-standing, although there will eventually be server-side protocol changes made to better support it (as well as further capabilities to be added to the libraries), which should further improve robustness and overall performance

Even without the server-side changes, the Lab hopes that the code itself will make things “a little bit better” for those using older routers, particularly Linksys WRT routers (Monty indicated server-side work would most probably be required to improve things for people using Belkin G-series routers)

While the libraries are close to what is expected to be the “final” code (barring bug-fixes, etc.), it is unlikely they will be integrated into the Development Viewer for at least the next two weeks. The reason for this is two-fold: The code needs to be merged-up with 3.4.0 Integration is dependent upon what kind of experience is had with the code “in the field”

LL hope that people will use the project viewer, and TPV developers will integrate it into experimental releases of their own, so that greater feedback (via JIRA entries, etc.) can be obtained in terms of: General experience reports – completeness, reliability, robustness, improved rezzing, etc. Whether the new code is helping to ease the strain faced by the likes of Linksys WRT routers, and what (if anything) it is doing to people’s home networks (From the TPV developers themselves) design comments on the code itself, whether it is felt things have been missed, if there are issues in integrating the code into TPVs, etc.



Again, note that the code is currently only related to textures; the “more ubiquitous” uses (as Oz has previously put it) of the new http library within the viewer have yet to be implemented, so HTTP inventory, etc., is currently unchanged.

Oz asked the question (of Monty), as to whether it would be a problem if TPV developers were to convert some of the additional HTTP functionality for use with the library. Monty didn’t see any major issues, other than the new library introduces the concept of a policy class, rather than the current global priority scheme, and this has not been fully implemented as yet, because it is not required in this first pass. However, additional functions could share the policy used for HTTP textures, and that would “still be productive”. Monty further indicated that there is a “to do list of intent” included in the code as a file, which TPV developers can look at if they are minded to look at committing to some of the work themselves.

Related Links