[sldev] LSL initiated Prim metadata was Re: Plugin architecture

Argent Stonecutter secret.argent at gmail.com
Tue Feb 27 14:37:41 PST 2007


On Feb 27, 2007, at 3:48 PM, Jason Giglio wrote:
> It is suitable only for *development*.  Not for deployment.  That  
> is by design.

Not even that: since it's untagged (and it is untagged, the way you  
describe it) then two people (developers) testing (developing)  
different features will step on each other's toes.

> It seems that you want something else, something that can be used  
> for deployment of arbitrary prim-property features without linden  
> implementation,

What I "want" is irrelevant. It doesn't matter what I want, or what  
you want, people will still do the same things no matter what your  
intention or my intention is. So, basically, I'm just telling you  
what will happen if this is implemented the way you describe. Because  
it's what's happened every time something like this has been  
implemented in any software system ever.

> This has little to do with LSL.  LSL is only a convenient server  
> side way to modify these properties *during feature development*.   
> In many cases the end server-side feature target might not be LSL.

Whether the server side target is LSL or not, prim properties are  
still serialized LSL lists.

>   The client feature surely has no idea about LSL lists and types,  
> and it shouldn't need to.

Any client feature dealing with prim properties will be dealing with  
serialized LSL lists.

> My CSG example on the wiki, for instance, that would more often be  
> set from the build tools, and might have nothing to do with LSL  
> after initial development.

The parameters set from build tools are also LSL lists.


More information about the SLDev mailing list