As of Friday Jessica was planning to put a release out to their current preview group. She was writing an invitation to ask more people into the preview group or maybe she meant she is inviting more people to a larger secondary preview group. It sounds like they will stage testing, so multiple groups may help. So, the viewer will soon go out to the first with the current preview group then, if things go well, a week later with the larger group.
You can see the invitation here: WANTED: Brave Early Adopters and Testers… This request makes it clear this will be a second group different than their beta testers.
A serious consideration is support. If you use a RC version they ask that you not ask for support from the Firestorm Support Group, as those users will not have access to the RC viewer you will be given. So, in my estimation you need to be an intermediate computer and viewer user. Because to a large part you will be on your own. You’ll have a way to report problems. But, there may be no fix or help for the problem you experience. The point of beta and RC viewers is to find bugs in the software.
This expanded testing suggests they are 3 weeks or more away from a public final version release. This looks to me to mean they will be releasing at the end of the month or early May. If things go worng that date will push back. But, there is pressure to release.
Caught Up
While Jessica says the Firestorm Viewer is caught up with the Linden’s SL Viewer, most FS Users cannot use the caught up version.
Since the FS Viewer is in feature lock, meaning no new features are being added, it has been falling behind the SL Viewer again as recent changes must wait the next release.
It is difficult to say when a viewer is current and there are a bunch of possible gotcha’s in any such statement. For a target to compare to one has to consider the main SL Viewer listed on the ‘download’ page as the current Linden release. It isn’t fair targeting the RC Viewers for comparison. Those change often as new stuff comes out of Linden QA and becomes public.
With the Lab working on a monthly release target schedule and Firestorm working on a quarterly release schedule, there is going to be some disparity between the two viewers. This last round of updating has been a large task for the FS Team and has pushed the time for this release to 6 months.
As it has been going, by the time a Firestorm version releases the Lab has a newer version with additional changes out that are not in the current Firestorm viewer. Viewer Managed Marketplace (VMM) is NOT going to be part of the coming Firestorm Release. But, they may get VMM added by the time VMM comes out of beta. I expect the Lab and FS to work together on scheduling VMM’s release. I also expect the next Firestorm Viewer release in way less than three months after this one releases.
Being behind is not always a bad thing. The Firestorm Team is very much a diverse set of eyes looking at the Linden code. There are going to be things they see differently and bugs they catch that Lindens have missed. If you have ever done proof reading, you understand the problem. Humans seldom do perfect. So, there are always mistakes to be found.
The result is the Firestorm Viewer tends to be more stable than the Linden viewer. The Linden viewer tends to get ‘infrastructure’ changes ahead of most TPD viewers, but it also gets unanticipated bugs. The TPD’s find many of those bugs and their fixes pass back to the Lab.
So, who is current? You probably start to see the problem. It depends what you are talking about, interested in, and doing with the viewer.
Firestorm Viewer remains the most popular viewer in Second Life. It is also the power users’ and RLV users’ viewer of choice for a majority of users.
Recent Problems
This past week has been hard on Firestorm users. The Tuesday rollout of a new server package to the main channel depreciated the UDP protocol formerly used for inventory download. The newer AISv3 (Agent Inventory Service) uses HTTP and its error correction to provide more reliable downloads. It also allows the use of pipelining, meaning one connection can be opened to download a number of items. Previously a connection opened for each item. That added considerable overhead opening and closing connections that has been eliminated with the HTTP Pipeline.
Firestorm KB/Wiki and support until March 31 recommended toggling HTTPInventory between disabled and enabled when a user had problems downloading inventory. People found that alleviated immediate problems and a considerable number left that setting disabled. This week FS Support had been helping those people get that feature enabled. The day I spent listening to the FS Support group not many knew what was happening and several people were getting into lengthy troubleshooting processes.
There is also an aversion that many in the support channel have to using Debug Settings to do quick settings changes. I think that is silly, but they have to deal with more users than I do. Since the KB/Wiki has many places where Debug Settings are referenced, I don’t see the problem. The problem comes when people mess with settings they don’t understand.
This HTTP thing hasn’t just been a Firestorm problem. A number of other third party viewers have had the same problem. And I suppose some that use the SL Viewer had disabled that feature. I’m not sure if the Lab disabled this setting in their recent versions of the viewer. But, expect that setting to disappear.
This coming release of Firestorm will have the setting enabled by default and removed from the menu control panels. It isn’t clear if they will leave it in the Debug Settings.
The Lab and their support team have not seen that many people coming to them to with the HTTPInventory problem.
Eventually the UDP code is going to be removed from the viewers. For now the ability to change the setting is just being removed.
So, if you are having problems with inventory; open Debug Settings, find HTTPInventory, and enable it. If you are a Firestorm user, you can ask for help changing HTTPInventory in the support group.
As far as I can see, there are no new testing groups. The Beta Testers are a select group of experienced and trusted people (including developers) who help with preliminary version testing and who get first pre-release testing on a proposed final version.
The Phoenix-Firestorm Preview Group to which Jessica is soliciting new members is a much wider group which gets a final crack at finding problems a few days to a week before final release. There are typically few if any problems by the time we (the preview group) get our hands on it. The wider testing does sometimes find problems though, do to the wider range of setups involved.
‘The newer AISv3 (Agent Inventory Service) uses HTTP and its error correction to provide more reliable downloads. It also allows the use of pipelining, meaning one connection can be opened to download a number of items. Previously a connection opened for each item. That added considerable overhead opening and closing connections that has been eliminated with the HTTP Pipeline.’
I’m sorry, Nalates, but as I already commented on you blog a few weeks ago, the HTTP inventory fetches *never used and are still not using pipelining*. See for yourself in the viewer sources (in indra/newview/llappcorehttp.cpp around lines 93-96). The only reason why HTTP fetches (which existed even before AISv3) are now faster is that a throttling delay was relaxed (see for yourself in indra/newview/llinventorymodelbackgroundfetch.cpp, in the comment around lines 55 to 61).
Also, I fail to see *any* problem with HTTP inventory fetches (they have been working for years before AISv3 and for over a year after AISv3 release in my viewer… The *only* problem, now, is when the HTTP inventory was disabled via a debug setting in TPVs, since the UDP path disappeared from SL’s servers in the last weeks; the Cool VL Viewer was updated to ignore that setting (which might still be useful in OpenSim) when connected to SL’s grid.