[sldev] LSL initiated Prim metadata was Re: Plugin architecture
gigstaggart at gmail.com
Tue Feb 27 13:48:16 PST 2007
Argent Stonecutter wrote:
> On Feb 27, 2007, at 1:25 PM, Jason Giglio wrote:
> -snip bunch of irrelevant crap-
>> You notice this has *nothing* to do with plugins, not directly.
> It doesn't matter whether you think it's got anything to do with plugins
> or not. If this is implemented in the server, people will use it for
> whatever they can use it for. If people can add code to a prim to pass
> information to the client, people will use it for that, no matter what
> you intend.
They can use it for whatever they want, it creates no burden on Linden
Lab if they abuse it. It's not suitable for this use, as you continue
to point out, as if it's a flaw.
> And you still have the problem that since it's untagged (and it is
> untagged, the way you describe it) then two people testing different
> features will step on each other's toes. No matter what you intend.
That is why it is not suitable for generic non-linden approved
communications to the client. That *is* the intent.
It is suitable only for *development*. Not for deployment. That is by
It seems that you want something else, something that can be used for
deployment of arbitrary prim-property features without linden
implementation, that is not the intent of this, and it is unsuitable for
this use, as you pointed out.
> Linden Labs already has a mechanism to pass actual property lists, real
> *lists*, typechecked in LSL, serialized for transport, and you want to
> jam it into strings?
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. The client
feature surely has no idea about LSL lists and types, and it shouldn't
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
> At the very least the tagged data needs to be a list, like all the other
> prim properties (primitive parameters, particle systems, etc).
No. There will never be a need for the user to modify any tag other
than 0 directly. You still seem to be under the impression that every
tag used this way will be directly script-accessible.
Some tags might get LSL wrapper functions, and some may not, either way
it's an irrelevant high level detail.
More information about the SLDev