[sldev] Rewriting the viewer (Re: sljirastats.com Linden Metrics Report)

[Lawson English]

Rob Lanphier wrote:
> On 4/18/08 1:30 PM, Jesse Barnett wrote:
>> Actually it was discussed extensively the first few weeks of SLDev & 
>> Rob coming on board in iirc and meetings under the umbrella of plugin 
>> architecture. I would imagine that the concensus has'nt changed from 
>> that time. Yes, it is a serious problem and yes, it should be done, 
>> but no, no one wants to tackle that beast and it is more expidient to 
>> just create sockets that interface the jumbled mess in the backend 
>> for the plugins to go. You hit the nail on the head with this : "I 
>> can understand any individual developer's reluctance to try to do it 
>> (HELL, I have no idea where to begin),"  It isn't just a matter of 
>> refactoring the GUI, the GUI is everywhere and would involve a major 
>> rewrite of ALL the code. The code sucks and everyone in the community 
>> and the Lindens know it sucks but continually hammering to get 
>> someone, anyone to rewrite it isn't going to be very productive.
>
> I'll restate what I stated last year on this topic, pointing to this 
> article from Joel Spolsky about Netscape:
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> I'm glad Firefox and Thunderbird are around, and I use both of them as 
> my primary apps for their respective functions.  However, while the 
> approach was eventually successful in producing some really important 
> software, it completely failed to achieve the desired result for 
> Netscape Corporation (and for that matter, AOL after that).  We intend 
> to survive the release of our source code ;-)
>
> The viewer architecture is in much better shape than it was this time 
> last year, and I think we have every reason to believe it will be much 
> better next year.
>
> Rob
>
>
I agree. Things have changed in drastic ways for the better since I 
started in SL in May of last year. And I said things badly. I didn't 
mean everything *needs* to be refactored, but that one has to examine 
what needs to be refactored from the ground up (base classes), since so 
many basic things are interacting in such odd ways at so many levels. 
Much/most of the code hopefully wouldn't need rewriting at all, or only 
piecemeal. And even the refactoring itself could be done piecemeal. But 
an understanding of where things are really pathological in their 
behavior is needed and all parts should be looked at as possible 
candidates of refactoring, no exceptions. That way, we catch all the 
potential gotchas (in theory at least).

Lawson