Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report

[Argent Stonecutter]

On 2008-04-19, at 05:05, Felix Duesenburg wrote:
> A compromise could be to switch on the custom build step only for  
> shelling out a new release viewer, and to leave it out while GUI  
> elements are being developed. I don't foresee a lot of problems/ 
> bugs that could occur only because of that step, because once  
> established it runs automatic, same as with Bison for the script  
> compiler. I find it hard to imagine that anyone would prefer to  
> have that ditched as well for a data driven approach?

I would.

I guess you didn't catch that when I say I routinely provide changes  
to the XML files for people to use, that's not limited to "first  
look" or "production", these are needed in all viewer. These have  
nothing to do with whether the viewer is in production or not, or  
whether one is a developer or not, they have to do with the fact that  
people have different preferences as to how they want the user  
interface of the browser to operate, and these files give them the  
ability to satisfy many of them without being a developer.

> Although this would enable the possibility to hook up any  
> programming language with the script engine by finding a way to  
> describe how it is to be translated into bytecode (current or mono).

This part of your comment I don't understand. What does the scripting  
language in-world have to do with the viewer user interface?

> The main point of this now is to shed light on the distinction  
> between what is/should be flexible for the developer for reaching a  
> better work economy, and what is/should be mutable/immutable to the  
> end user or "light developer" (i.e. skinning, customizing the  
> surface only).

Ideally the entire user interface should be implemented completely in  
a scripting language (Javascript, Lua, Tcl, Python, etc) with only  
the actual "in-world" part implemented in a compiled language at all.  
This should improve the reliability of the viewer, because it would  
reduce the amount of code that is subject to buffer overflows, null  
pointers, wild pointers, memory management problems, and so on,  
because there are many many more eyes looking for these problems in  
the scripting language runtime.

> I don't think there's an argument that there has to be a certain  
> core which the user is not to touch, and that strictly ought to be  
> developed with the goal of stability.

Yes, there is an argument there.

The user should have access to everything in the viewer user  
interface where it does not impact performance.