[sldev] LSL initiated Prim metadata was Re: Plugin architecture
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
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