I have just spent the last hour or two reading the blog on this topic. The quality of the discussion is so completely uninformed from essentially a few people that are being allowed to monopolize the comment threads that it is almost dysfunctional.
So I am going to comment here where at least people with some idea of what the issues are will see it. I see a clear benefit of having a list of SL browsers that are "recognized by LL" to be, say, well behaved, not likely to steal the user's account details, or intentionally corrupt their machine, or duplicate their content and email it to the chattering masses. But that is where it stops. The idea that a registration system should (or even could) be devised that forces each browser to be pre-approved before accessing SL would e3ffectively halt OS development and defeat the a key purpose of OS'ing the code in the first place. Why? Firstly, because the development life cycle is to test the thing being developed under real world load and conditions. Something that can only be done on the grid - until the server code is OS'd as well. Secondly, a key advantage of OS is the flux in the development and product pool: the ability to pursue many similar paths across many teams concurrently so that innovation occurs and gradually the better, more useful solutions emerge. The whole point is a lack of stability across the entire development tree but stability within each branch and trunk. Once registration and authorization is mandatory the branches cease to stray from the trunk. Thirdly, the cost in time and resources for LL to code verify every candidate browser would defeat the economic benefit of LL outsourcing it in the first place, and the diversion of resources from server enhancement, and key feature innovation would increase the risk of a competitor duplicating and catching up to the SL solution. They would be better scrapping the OS browser's all together. Fourthly, it is too late. The key information about how everything works is already "out of the bag", so any attempt to close it without massively changing the server interface would be ineffective. Fifthly, the suggestion made by some on the list that a binary hash code could be used to verify the integrity of the browser version connecting (a-la-unix code version verification) ignores the fact that (a) the browser can report any number it likes to the hash request, and even if that could be avoided, no one can stop me writing an injection dll and hooking directly to the winproc, the ports, dynamically replacing procedure calls or wrapping the OpenGL dll or the win32 dll, or any one of a dozen other ways I can inject my own library into an otherwise legitimate app - that will continue to report the hashcode correctly, once it has loaded. Anyone who doubts me and has a Logitech camera attached to the computer - take a look in the windows temp folder for a dll called Lvprcinj***.dll - that is the Logitech injection dll that ensures the camera can always function regardless of what is running. I think a registry is a good idea to protect non-programmers who want to download an alternate viewer in safety. Beyond that - for example as an enforcement tool - it is a waste of valuable resources. And yes, I am a content developer who wishes copybot (et al) did not exist, but I would not for a moment claim the world should be made "safer" by tieing the thumbs of the browser developers. As someone who essentially uses the LL viewer, I have no personal position to protect with respect to the OS browsers - but I 100% support what is being done by the OS developers, and am very concerned that the predominant tone of the comments in the blog thread is dangerously uninformed, self interested, destructive and simply technically wrong. Regards Jonathan Bishop _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
