22 July 2013

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.

10 comments:

  1. Tonya, please... Stop spreading FUD. The problem with multiple COF folders has nothing to do with the Cool VL Viewer per see: it's all about v1 viewers (ALL of them, not just the ***old*** Cool VL Viewer release !) considering the COF as a normal folder and consequently allowing to move it or delete it altogether.

    Since it has been supporting SSB (first Cool VL Viewer release with SSB support was v1.26.7.5, released back on January the 11th), the COF is used just like in v2/3 viewers with the exception of initial outfit restoration (it would be too long to explain why here, but I already countless times developed the arguments). Initial outfit restoration is not either the issue here (and was largely improved on the compatibility aspect for viewer-switchers: there's no outfit mix-up any more between outfits when you switch from a v2/3 viewer to the recent Cool VL Viewer releases).

    Like I replied to Nyx in an email:
    "My viewer follows LL's protocol for baking. It doesn't use the same outfit
    restoration algorithm on login, but it is compatible nonetheless (Hell, I
    would know first hand: I use my viewer every day !!!).

    Now, I cannot do anything if people using my viewer do not update at the
    same pace as I provide updates (i.e. weekly): if they use deprecated
    versions or releases, I cannot do anything about it (like you could not,
    at LL, prevent the 1500+ different "flavours" of viewers to connect to SL).

    If you have issues with some Cool VL Viewer users, please point them to
    the support forum (some persons just won't read the viewer TOS neither
    the Help menu items that would point them directly to that forum): these
    issues have already been largely discussed and explained there, so they
    would find the solution to their problem.
    "

    Instead of accusing me and my viewer to be the culprit for such issues, you could have pointed out to users of now deprecated viewers how such a usage can be dangerous and inappropriate. Should they use *any* SSB-compatible viewer (Cool VL Viewer included) they won't have any issue.

    ReplyDelete
    Replies
    1. I just tried deleting or moving the COF on both 1.23 and Phoenix 373, which was pre-COF support. Neither would allow me to do so. That's because the COF on that account was created successfully, as a system folder. If a user can delete or move it, it would be because the folder was created incorrectly, without the proper folder type. (Or that the viewer had a bug that allowed system folders to be moved or deleted, but that's worse.)

      No, I can't do anything about users who insist on running outdated viewer releases, and neither can you or anyone else. (With the exception of LL; I'm sure they'd be happy to block releases that caused problems for SL.)

      And you must have missed the repeated times I've told people in this very blog to update their viewers, now.

      You may not like the conclusion I draw from the available facts. The facts don't change because you don't like them. The fact is that SUN-99 only affects CoolVL users. The fact is that the COF winds up duplicated, or worse. The fact is that we were made aware of this because of a user who had trouble changing outfits in Firestorm and came to the Firestorm support team when the changes wouldn't work on SSB regions.

      You've done a lot of good work over the years. You've helped improve the Second life experience for many more people than the ones who use CoolVL. I have a lot of respect for that, and for the single-minded dedication that you demonstrate. That doesn't change the fact that nobody's perfect; not us, and not you. We own our mistakes and fix them. If CoolVL doesn't have that problem *now*, then that's great. It doesn't help the folks who have it from earlier releases.

      As I said at the top of this post, we have different approaches to viewer development. You've been criticizing ours, just as I've been criticizing yours. Each of our approaches has its advantages and its disadvantages.

      I'm not acting out of bad faith; I'm putting the facts in front of people, along with my honest opinions honestly arrived at. I'm willing to change my opinions if the facts they're based on change. I don't spread FUD. I also refuse to be politically correct. I calls 'em as I sees 'em. Don't like my opinions? Fine. I have no problem with people disagreeing with me. But don't accuse me of bad faith.

      Delete
  2. People will judge on *real* facts (nor fantasized ones: one user reporting a bug caused by their use a deprecated release of *any* viewer is not the end of the (virtual) world !). Just be careful not making a fool out of yourself and yes, this is FUD when you say its' the Cool VL Viewer and my fault, because current SSB-enabled releases of my viewer JUST CANNOT lead to such a bug.

    ReplyDelete
    Replies
    1. The Firestorm support team tells me it's not just one user, and the common thread among all of them is that they're CoolVL users.

      How many times have you had code fall into the "can't happen" path? If you say "zero", you're full of prunes. What the code actually does beats what the code should do every time. An experienced software professional like you knows this. I would suggest that you quit saying "it can't do that" and find out how it did.

      Delete
  3. Then let me repeat it again, one last time: IT CAN'T HAPPEN WITH CURRENT COOL VL VIEWER RELEASES (they are all SSB-enabled, they do not allow to move, delete (or even manually add or move items into) the COF, they would always create a missing COF at the inventory root).
    Again, this is an issue with people using DEPRECATED versions/releases.

    ReplyDelete
    Replies
    1. Then how do you explain FIRE-11089, from a user of a CoolVL version with FMODEx 4.44.17 ?

      Delete
    2. The person in question probably used a non-SSB release, deleted the COF and forgot to empty their trash, or they moved the COF (such as in the Clothing folder) and they upgraded to a SSB-enabled viewer that, not finding the COF at the root, recreated the COF at the root folder (LL's viewer behaves in exactly the same way in this respect: the same code is used to check and recreate a missing COF).

      AGAIN, it's an issue with people using deprecated viewers, the current releases CANNOT move or delete the COF.

      If you don't believe me, then perhaps you are ready to take another bet (that you will loose): I bet you cannot provide me with repro steps that would allow you to create a second COF, or to delete or move the COF with the current releases.

      Delete
    3. (Your comment somehow triggered Blogger's spam filter. I don't know why. I published it as soon as you pointed it out. Despite your indignant IM, I did not, and do not, censor this blog.)

      Fine. Point me at a viewer that can move or delete the COF. So far, 1.23 and Phoenix 373 can't. Those are just as deprecated as older versions of your viewer, and yet I can't touch the COF with either one. You say I can't reproduce your problem. Until you can, then your claim rings hollow.

      Delete
  4. I found it hard not to comment back on this. But, right now an account I used to own suffer from this issue. The account has two 'Current Outfit' folders. One in the inventory folder and another one hidden under the cloths folder. The fake one had a skin and hair layer that was baffling us because no matter how much we replaced outfit or whatever we changed, it won't go away nor could we find where it was located and the account just appears borked to others except the main user.

    Someone in the SL question answer forum on the website asked us to check if we had two current outfit folder which indeed we had. I used to use CoolVL viewer with that account six months ago. But I rarely logged into that account and the person I passed it onto uses firestorm (Latest version) and only now got into this problem. Our only solution is to file a ticket apparently, but being a non premium member, LL may not fix the issue that quick.

    I was a frequent user of CoolVL viewer up until last month when I upgraded my laptop. I really love the viewer a lot because it allowed me to actually stay logged into SL and enjoy the experience considering my laptop was really old and worn out. But I find it sad if any of my accounts would suffer from this issue and I guess the only way to fix it may be to become a premium member. Whosoever's mistake it was won't really solve the issue anyways. But thanks for posting this blog entry since it provides great awareness for people like me who ain't all tech-savvy. T_T

    http://community.secondlife.com/t5/Avatar/avatar-aint-rezing-skin-or-alpha-layers/qaq-p/2151729/comment-id/13857
    -Above is the link where the COF thing was mentioned.

    http://community.secondlife.com/t5/Technical/Does-anyone-else-have-a-solution/qaq-p/2150703
    -What I posted initially about everything we tried to get the account to work out and even what the 'answer' says to try. Nothing worked.

    Just incase there are others who have the same problem. If the issue on my side is ever fixed, I'll surely post an update here on how long it took.

    ReplyDelete
  5. Oh, to follow up on my previous comment. LL was really quick to fix the issue. =D Really great! So everything is fine!!! =D

    ReplyDelete