[sldev] Re: Feature freeze

[Lawson English]

Paul Oppenheim (Poppy Linden) wrote:
[...]
> Lawson English wrote:
>> Well, some bugs and source code oddities in the graphics subsystem 
>> were automatically fixed/corrected by the Windlight team, so its 
>> counter-productive to say "no new features" when new features are 
>> going to fix certain bugs/issues for free as part of deploying said 
>> new feature.
>
> *** THANK YOU! ***
>
> There's quite a bit more of that on the horizon, as you probably know.
>
Yep. I'm involved mildly by trying to do docs as theprotocols are developed.

https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Rez_Avatar_Capability


>> An even more drastic proposal on MY part is to refactor the  client 
>> with clean divisions of the GUI and the other subsystems, but for 
>> some reason, few programmers who contribute to SL apparently see a 
>> need for this...
>
> ... and that makes me a Sad Panda.
>
> I recently tried to push internally for this. I got kinda deflected, 
> because we have plenty of other APIs yet to design / code that we've 
> already promised. (hello, AWG!) I'd *love* to see this as the first 
> step toward moving forward on that viewer plugin SDK (not to be 
> confused with a viewer scripting API) that everyone's been talking 
> about. I don't work on the viewer now, so I'm not the best person to 
> be rambling about this, but I do think what it would buy us alone in 
> testing would be worth it. I know at least one Linden who could rant 
> about how awesome automated testing becomes with an architecture like 
> that.
>
It's sad. It seems a no-brainer to me that that LL has to hire a decent 
crew of folks to re-factor the client from the bottom up and get the GUI 
into shape. There's things that could be done with a SL-specific GUI 
that would be overwhelmingly kool. E.G. have windlight-based animated 
skins: if you enter a goth zone, you get dreary GUI elements complete 
with dripping water when it rains. Combat sims would get explosion 
flickering and so on. In theory, you could patch the current client to 
get those effects, but  the GUI is so inefficient (from what little I've 
seen) that it would be a fps-killer. With the right redesign, I'm 
positive you could play with all sorts of things in the viewer without 
impacting the framerate much, if at all.

Refactoring things properly, you'd get the plug-in architecture, 
scripting architecture, lightweight clients, uber GUI skins, etc. And 
debugging would be a breeze compared to now.


> Unfortunately it's really hard work for what may be seen as little 
> benefit. A case needs to be made that a modular architecture is more 
> important than, say, agni DB scalability, inventory loss, LSL 
> refactoring, build system refactoring, or whatever else engineering is 
> working on. (Contrary to belief, not everyone is working on "flashy 
> new features" no matter how often people repeat that meme with no 
> actual internal information.) It's also more difficult than your 
> average task, because you're essentially developing an API, which you 
> Better Not Screw Up.

Well, thing is, it could be done in parallel with everything else if the 
APIs were properly documented (those who have ears, let them hear...).

>
> There have been a few "viewer cleanup" branches going out which should 
> be a step in the right direction, but aren't close to this. If you're 
> interested and have experience doing modularizations like this, start 
> to think about it and make some proposals. There's the AWG protocol 
> development for the sim and grids, but no protocol working groups for 
> the viewer. Make it happen!
>

Problem is, everyone wants immediate results so they're involved with 
libsl, realXtend or openviewer.

Some of us set up a VAG for a modular viewer test harness which could be 
raided by anyone for ideas and code, but aside from my preliminary 
python login scripts, which really just test the AWG protocol docs, 
no-one's done anything with it.

https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft


Lawson