There is an article by Hamlet, Future Phoenix Viewer Development in Peril?, that points to a post by one of the Phoenix-Firestorm developers, Tonya Souther. See: Viewer 1 is officially on borrowed time. The title says it pretty clearly. The writing is on the wall, Phoenix is a dying viewer with an expected near term death. While Hamlet focused on Phoenix, there are problems ahead for any V1 viewer. Well… actually any number of viewers brands.
Shining
Near the end of June an announcement was made about the projects Linden Lab™ will be working on for the next few months. See: Project Shining to Improve Avatar and Object Streaming Speeds and my article Second Life Changes Coming.
HTTP
HTTP stands for Hyper Text Transfer Protocol. If you’re curious about the more technical but simple definition read The Webopedia definition of HTTP. For an even more technical explanation see: What’s HTTP? Explain HTTP Request and HTTP Response.
The important aspect of HTTP for Second Life™ users is that it uses TCP. Lots of acronyms, I know. But, spelling them out is tedious. TCP=Transmission Control Protocol. The key word here is: Control.
Many of the current Second Life services and even more of past services use or have used UDP (User Datagram Protocol). UDP’s redeeming quality is simplicity and lack of control, a just do it mentality. The Wikipedia says, “Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets.” At one time it made sense for the Lab to use UDP. The advances in hardware and technology have improved and connections are way faster, which reduces the need for the Lab to use UDP.
HTTP is more complex. It pushes much of the complexity into the hardware. Routers and network cards take over the duties of error correction, to some extent data encryption/decryption, and data compression/decompression. An application has way less work to do and requires less coding. So, to the application HTTP appears to be much simpler.
The Lab’s HTTP
The Lab is always pressed for time. Their initial HTTP code was not the total master piece of all inclusive code they or any of us would have liked now. But, for the time, it did its job. Now that is changing. The Shining project will build a new HTTP ‘foundation’ for Second Life. I suspect the research into the Avatar Bake Problems (See: #SL Clouds, Grey, and Blurry Avatars) revealed these problems and resulted in, or at least contributed to, the decision to redo the HTTP services of Second Life.
HTTP Impact
The Lab is rewriting their HTTP library and changing a number of services… well ALL the UDP services and the HTTP services to use the new HTTP library. The Lab will be standing up new servers to provide existing services now provided over UDP to provide them via HTTP. At some point the Lab will be taking down the UDP servers.
A byproduct of the change is the stress placed on older routers will be less. Some of the LinkSys WRT and Belkin routers may, keyword may, start working again. Locations where more than one SL user is on will work better. Wireless will likely work better.
When those UDP servers go down, old versions of viewers that do not use the new HTTP will have more and more services/features that do not work. We know the Lab will not be upgrading SL Viewer 1.23.x. So, it is doomed as are all old versions that are not upgraded.
The Phoenix-Firestorm team was to meet 7/15 to decide what they would do about the Phoenix Viewer. As yet, I have not seen an announcement. The PH-FS Team seems more terrified of the users than do the Lindens. So, I am sure they are waiting to get the preliminary code and information on the new HTTP Library before deciding. If integrating the new code is going to be difficult, then the Phoenix Viewer is likely doomed. If not…
We won’t be replacing all uses of UDP – there are still plenty of things for which it is and will remain the right thing. For example, position updates for things in the world make more sense to send via UDP – if one is lost, the next one corrects it anyway, so having the underlying protocol resend is a waste of time and makes successful deliveries less timely.
But for things like transferring image files, HTTP is significantly better when used well, so we’re going to transition those uses that make sense.
Thanks for the correction.
I kept reading “Composting Service” —– some kind of Freudian expectation slip I suspect.
You are right about the crying and wailing, “SL has run perfectly well on this computer I bought for $400 in 2006, why have the Lindens forsaken me?” and such.
LOL… I didn’t even notice. It is a typo, but I suppose typos can Freudian.
A more efficient solution to using the Current Outfit folder has been proposed by Henri Beauchamp of the Cool VL Viewer : http://sldev.free.fr/forum/viewtopic.php?f=5&t=858
Another thing I would like to point out is that both Jessica and Tonya have never really liked updating the Phoenix Viewer and that it was carried out mostly by LordGregGreg and a few others on the Phoenix/Firestorm team. There website in fact, is still The Phoenix Viewer website, not The Firestorm Viewer website. I would wait until an official announcement is made before jumping to conclusions that The Phoenix Viewer is dead.
You wouldn’t jump. I probably would.
There are hold outs that keep working with converting V1 and Snowglobe code to work with new V3 code. That may well happen with Phoenix. But, those viewers are falling behind and I think they will likely continue to fall behind. I think Henri’s Cool VL Viewer is probably a unique exception. His is V3 code based with a V1 interface. He waited for the Lab’s development direction to stabilize then made Cool VL. He seems to stay current. If one wants to stay in a V1 interface, Henri’s is a good if not the best choice, IMO.
As far as I understood it Henri’s viewer is Viewer 1 based but includes various elements that are Viewer 3 based – most notably the rendering stream. Of course Henri has modified much so maybe such definitions are not so useful.
Henri has been vocal on the point. So, unless I’m misunderstanding him, it is V3 code with a V1 interface.
Starting with v1.25.0.0, The Cool VL Viewer was based off Snowglobe v1.5 and some of the v2 code (alpha and tattoos, inventory links, etc) where backported to it (in fact, some code was already backported to the Cool SL Viewer v1.23 and even v1.19.2, which were based on LL’s v1.23 and v1.19.0.5 respectively).
With v1.26.0, more and more v2 code was incorporated, replacing the corresponding Snowglobe code. This was particularly true of almost all the project libraries (all the ll* directories in the source tree that are not inside newview/ but along it), but also of many classes in newview/ (texture fetching (HTTP) and caching related, for example, but not only).
With v1.26.1/2, things went even farther since it saw the inclusion of all the rendering code from v2.6 (with further improvements/fixes coming from v2.7, 2.8 and 3.0). More newview/ v3 code was also backported (new web search, inventory changes (HTTP fetches, marketplace support…), etc, etc…).
The mesh versions of Phoenix are in fact based off the Cool VL Viewer v1.26.2 (at least for some of the ll* project libraries needed by the mesh code, and of course, the mesh renderer).
With v1.26.3/4, the whole texture layers, parameters and avatars compositing/rendering code was backported from v3.2 together with more inventory code changes (which brought multi-layers clothing support) and even more code was updated/backported from v3.2/3.3.
With v1.26.5, I’m currently backporting the v3.3 renderer…
And the story continues and will continue as long as I am intested in SL/OpenSim…
One thing is sure: I’ll keep the Cool VL Viewer up to date with LL’s viewer while keeping the v1 UI (unless LL comes up with another UI that can beat v1’s efficiency, but even the v3 FUI is still *very* far of that !).
So, yes, the Cool VL Viewer is *mostly* a v3 viewer with a v1 UI, even if the UI-related code often goes deeper than just the way the UI elements are drawn on the screen (the inventory, for example, is dealt with in the v1 way, which presents quite some differences from v3), meaning there is still some non-UI-only v1 code in the Cool VL Viewer…
I am very glad to hear that the lab is pushing forward with changes to the infrastructure. You can only hold on to the past for so long. Microsoft spent far to many years fighting to maintain compatibility, and it hurt them. I am happy that LL is moving forward even if it does mean that some of these older viewer will cease to function. I am very happy to hear as well that consideration is being given to each function to pick the best protocol to deliver that functionality. I am very, very excited to see what happens over the next 4 – 12 months in SL.
Me too! 🙂
In this context, the word “exciting” scares me.
I want the way the Viewer talks to the servers to be boring. I don’t want to be surprised. I don’t want to notice things happening, or not happening.
I hear that one or two bad decisions were taken in the original use of HTTP, involving the keep_alive option, and current viewers have adapted to cope. It’s that adaption which is straining routers.
It would be simple for Linden Labs to make sure that keep_alive was turned on for existing servers, but the Viewer adaptions could then backfire badly. A large number of HTTP Sessions would be opened to get around the lack of keep_alive, and if they requested keep_alive anyway, they would stay open.
That’s the story I heard. It makes some sense to me.
Fixing this mess needs good communication on the part of Linden Labs. They do seem to talk a bit more to the developers than they do to us ordinary residents, but fixing this needs the developers to produce viewers that don’t behave badly when keep_alive is active, and it needs residents to be confident they should use them, and all this lined up for when the Lindens push the big red button.
Linden Labs do not have a good reputation for communication. And residents do cling to the old, the familiar, and the predictable. (I didn’t switch from Phoenix to Firestorm at the first opportunity). There might be horribly complicated ways of making the Viewer switch automatically when it notices keep_alive is working. Even if that is simple, it will need testing.
This isn’t going to be fun.
Well… the Lindens in general exhibit better communications skills than the community of users does.
As the Lab moves their product to use more multi-threaded processes the HTTP communications will have become fastidious about closing connections.
I mean… why all this time wasting? The V3 interface is amazing. Minimalistic, professional looking (The gray tone matches the most advanced UIs like by Adobe, and nowadays many others are starting to adopt this kind UI. No confusion, no fancy elements. A contestual menu is faster than a pie menu.
It’s not my opinion – otherwise Apple and Microsoft should be crazy to prefer it, don’t you agree?
Plus, you need more hand gestures, more clicks to achieve simple task. Tabbed IMs? Tabbing could be great for web browsing, not for a multiple chat, otherwise all the most popular social networks whould be crazy to adopt separate IMs popups, don’t you agree? It’s paranoid to get used to something and don’t even try to update yourself. I mentioned just these few examples but there are more. When I joined SL, I wasted 2 weeks with V1 trying to figure the basics, and I gave up. When I switched to viewer 2, in less than a week I realized all the basics, and more. For oldbies of course it’s different, but the learning curve with the lastest viewer UI for new users it’s several times faster -and following the experience of users and new users I know- I have proofs of this).