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

[Jason Giglio]

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 
design.

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 
need to.

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.

> 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.

-Jason