The following notes are taken from the TPV Developer meeting held on Friday October 4th. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each head denote the time stamp at which the topic can be listened-to in the video.
Release Pipeline Recap
Maintenance RC viewer 184.108.40.2061793 was promoted to the de-facto release viewer overnight on the 3rd/4th October (release notes). This primarily comprises:
- Viewer-side support for new LSL particle capabilities (blend, glow, ribbon)
- The automatic avatar render limit and feedback system
- Fixes for the Cocoa release regression issues (see below)
- Fix to prevent orientation being lost on teleporting (if you’re facing west when you teleport, you’ll still be facing west on arrival)
- Further bug fixes as listed in the release notes, including further CHUI and materials fixes
The remaining release candidates (Google Breakpad, SLShare and the Snowstorm contributions RC) continue to produce good numbers, and the Lab hasn’t seen any major issues with them.
Interest List Viewer Updates
It is currently anticipated that the viewer-side code supporting the recent batch of work on the interest list will finally arrive in week 41 as a release candidate viewer. This will be discussed at the next TPV Developer meeting, scheduled for Friday October 11th.
Mac OS X 10.6
[41:00 – 45:40]
As reported here, recent updates with Cocoa on the Mac viewer led to users still running Mac OS X 10.6 to experience some “obnoxious problems“. As a result, the Lab initially implemented a mandatory roll-back of viewers for users on OS X 10.6 to viewer release 220.127.116.110048 (August 20th, 2013). However, some of the issues have been resolved fixes within the last maintenance RC viewer (18.104.22.1681793), which as noted above has now been promoted to the de facto release viewer. As a result, the roll-back to version 22.214.171.1240048 has now been made optional and has been left available until such time as the remaining issues with Cocoa and OS X 10.6 can hopefully be addressed.
A broader advisory from the Lab is that as the viewer is a lot more stable on later version of the Mac operating system, those who are on OS X10.6 and in a position to upgrade should consider doing so.
Other Potential Viewer RCs
[40:12 – 41:00]
The next round(s) of viewer releases from the Lab are expected to include:
- A further maintenance viewer RC
- The SSA / AIS v3 viewer updates (anticipated in the next couple of weeks – see below)
- Monty Linden’s viewer-side HTTP updates, which are currently on internal QA at the Lab.
Advanced Inventory Service (AIS v3)
[02:18 – 15:02]
The inventory service updates, initially being undertaken alongside Server-side Appearance (SSA), are now ready for deployment.
A core part of AIS v3 covers the inventory changes that the second round of SSA updates use to manage the Current Outfit Folder (COF) more reliably, including hopefully improving the response time for re-requests for an inventory item / update; however there is more to the updates than this.
Two wiki documents have been produced for the new API:
- The Inventory API v3 overview
- The Inventory API v3 raw code (being used internally by the Lab for unit testing)
Don Linden expanded on the purpose of the update, saying:
The main reason for this update is that a lot of the messages we currently have for manipulating inventory are based upon UDP, and they are not really reliable; there may be an error that occurs in the back-end somewhere, but the viewer doesn’t really get an update that there was an issue there. Also there are some issues around single-threaded pipeline on some queries and the way that they’re routed [and the changes] should help support multiple inventory operations at once using different back ends.
The updates should also give more control to the viewer about what it wants to do with the inventory without necessarily having to go through the simulator when working with one’s own inventory or the Library inventory; the viewer will communicate directly with the inventory service. However, certain capabilities will remain unchanged – such as not being able to copy personal inventory items to the Library inventory and not being able to delete items from the Library inventory. Additionally, avatar-to-avatar inventory transactions (such as giving another avatar an item from your own inventory) will still be handled through the simulator. The new service also should not result in any change in behaviour in terms of notifications users receive as a result of inventory actions (such as a notification that a new item has been received into inventory).
The new capabilities are designed to run alongside the existing inventory API (“v2”), and will require a viewer update to access them. The current plan is to deploy the server-side AIS v3 code to Aditi, where TPVs are invited to carry out tests using current viewers to ensure that the AIS v3 code is not inadvertently impacting on the “v2” code in any unexpected ways. As the updated viewer code becomes available, TPVs will be able to incorporate it into test versions of their viewer to test the new capabilities directly.
Commenting on the availability of the updated viewer code (which is integrated with SSA updates), Nyx Linden indicated that it should be available to TPVs in the “next week or two”. He also requested that while they will then be able to merge it for testing purposes, they do not add the code to release versions of their viewers until the Lab formally releases it.
An interesting element of the AIS v3 API changes is that as well as using Linden Lab Structured Data (LLSD), it also supports the use of JSON, which may be of an advantage to non-viewer clients.
Group Ban List
Internal testing of the new group ban function will commence in week 41. The ban list itself will be capped at 500 per group. Speaking at the TPV Developer meeting, Baker Linden highlighted some key aspects of the new functionality:
- The default ability to ban / unban avatars from a group will initially be limited to group owners
- There will be a new ability for banning that group owners can assign to specific roles within the group, if they so wish, to allow others to ban people
- Those banned will be listed in a new sub-tab called “Banned Agents” (or similar) within the Group Profile Floater under Members and Roles
- Banned avatars will be listed by name / ID and the date on which they were banned
- The actual database managing groups now includes a “reason” field to specify the reason for banning an individual, although the ability to add a reason will not be implemented viewer-side in the initial release
- The “reason” ability will likely take the form of a number of options which can be selected when banning an individual, rather than simply being a free format text field (although it may include an “other” option). This should add greater flexibility when sorting / ordering the ban list or when carrying out bulk actions (such as bulk unbanning by reason)
- The capability supports pre-emptive banning (as with parcel / estate bans): avatars can be selected via a name picker in the same way as the group invite function works, and added to the ban list (which will prevent them from joining the group); this includes the ability to bulk ban
- When banning someone who is already a member of a group, the function will add them to the ban list and then call the existing group eject function, which will then eject them from the group
- If a group member attempts to invite someone into a group when that person is already on the ban list, the person making the invitation will be notified that this is the case
- No notifications are currently sent to a person if they are banned, or if they try to join a group when they have been banned; this may change between now and the time the capability is deployed to the main grid
- Time-based banning (such as banning an individual from a group for a two-week period, for example) will not form a part of the capability
- Initially, there will be no LSL extension for group bans (so not scripted ban capability). However, Baker is considering discussing this with Kelly Linden at some point in the future.
The one thing the group ban capability will not address is the bug which allows people ejected from a group to continue to spam group until such time as they close the group chat window. It will therefore still be necessary to block troublemakers from using group chat prior to banning them until the underlying bug with group ejections is fixed.
In explaining the work carried out to date, Baker also re-iterated his work on eliminating leading spaces (including unicode spaces) from display names and on fixing the problem whereby removing an avatar or object from a block list didn’t actually always remove them / it from the list, even through the viewer appeared to go through the motions of doing so (and you’d have to try removing them / it again).
With thanks to Northspring for the video.