A difference in approach

There's been a lot of back and forth between me and Henri Beauchamp, and me and Siana Gearz and to a lesser extent Latif Khalifa, about the difference in development approaches between Firestorm on the one hand and CoolVL and Singularity on the other.

Henri commented, on an earlier entry on this blog,

Using the wrong tools (a code repo) and method (merges, instead of a a true fork and backports), you waste your time while I work alone but much faster.
For your info, the *only* tools I'm using to program are a text editor (nedit), and the 'grep', 'diff' and 'patch' commands.

He also noted, in another comment,

Also, April is quite late for SSB support (I had it fully working and released in January, i.e. 3 months sooner)

There's only one problem, but it's a doozy. As it turns out, his SSB code has a major bug in it. SUN-99 describes a corruption in the Current Outfit folder (COF) that is caused by CoolVL's implementation. It only affects those who use CoolVL and change outfits in SSB regions. The result is multiple copies of the COF. This cannot be fixed by a viewer. It requires Linden intervention. Since the SSB servers depend on it being right, the user's avatar never updates correctly, and thus their appearance is broken for everyone but the user themselves.

Henri has never made it any secret that he disagrees strongly with the whole idea of the COF. In a comment on Nalates Urriah's blog, Henri rips it up one side and down the other, explaining how it was not necessary, that LL's old way of doing the equivalent could have been extended to handle multi-attach (the original reason for the COF), and that his method of doing it is superior.

That all may well be true. Unfortunately, there's one major flaw in his thinking: The viewer interacts with the Second Life servers. Those servers have very specific expectations of how the viewer will behave. Henri's viewer does not behave that way. Instead of using LL's code which is known to work with the server, he implemented his own - and got it wrong, to his users' detriment.

(And all of this is quite aside from one problem with his implementation that the COF doesn't suffer: his implementation makes what you wear at login be the same thing you were wearing when you last logged out on that computer. If you switch computers and change outfits, when you go back to the original machine, you'll change back. This is not what the user expects.)

The same thing goes for Singularity, in a different area of the viewer. Monty Linden has done a lot of work on the HTTP server and client in the LL server and viewer. The original implementations were broken in a number of ways, and caused many strange and wonderful problems in the viewer and the users' experience. Monty rewrote large portions of that to do things in a much more standards-compliant way. Included in that is a throttling mechanism to prevent one or a small number of users from hogging the simulator resources and making everyone else's responsiveness worse.

Singularity's Aleric Inglewood thought he could do HTTP better than LL. While he started before LL announced their improvements, he stuck with his code even after Monty's was released. The results have turned out different from what he expected. Now he's struggling to find ways around the throttles, and wiring in fallbacks to the old way of fetching textures via UDP when that fails. Since meshes can only be fetched via HTTP, he's kinda stuck there.

Again, this is because the SL servers expect the viewer to act in a particular way and don't deal well with those that do not. In this case, it's an active defense, instead of a simple breakage, but the results are still the same: a broken user experience.

This kind of incompatibility is one major reason we don't reimplement any functions that go straight to the LL servers. We can and do make user interface changes. We keep our cotton-pickin' fingers out of the server interface code.

Nyx Linden just sent out a long email to the TPV developers' list outlining exactly how the viewer should treat the COF, including things to verify in the code. Since we use the code from the release viewer, I don't expect we'll have to spend much time on that. Henri's got some work ahead of him.

This ties in with a related point: when LL rolls a new feature, we can implement it by just using their code and splicing in our changes. We don't have to backport it. We certainly don't have to rewrite it, let alone reinvent it. We can just use it. We deliberately chose to hack on the V3 UI, trying to maximize the amount of code in common between V3 and Firestorm, instead of welding the Phoenix UI code on the side for this reason.

Henri may be able to do things faster, but a wrong answer is still wrong no matter how fast you get it.

Yes, we do seem to piddle around and take our own sweet time and waste time on QA (according to Niran) and so on...but when we release it, we get it right.

So I'm not particularly interested in how Henri or Singularity's development model may be better than Firestorm's. I care much more about putting out a viewer that users can depend on, first time every time, and that gets the job done without screwing up users' inventories or hammering the LL servers. No, we're not perfect (see Firestorm 4.4.1). We can always improve. We know enough to realize that. So do our users, and that's what really matters.