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

[Jason Giglio]

Jacek Antonelli wrote:
> On 2/27/07, Jason Giglio <gigstaggart at gmail.com> wrote:
>> 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.
> 
> Perhaps I am ignorant and blind, but it seems to me that implementing
> "arbitrary prim attributes for use" yields "... for testing" at no
> additional cost, in addition to being a genuinely useful idea in
> itself. To put it briefly: for-use has everything we want from
> for-testing, plus a cherry on top.

That is a valid avenue to explore.  I considered this when writing my 
proposal and rejected it for the following reasons:

1. Fracturing the metaverse with content only viewable with certain 
plugins, like the web is/was.

2. Because of this, it's a controversial change.

3. The main reason, it was not necessary to accomplish what I wanted to 
accomplish with my proposal.  Simple is better.


> What
> are the concerns about for-use? Less secure? More work to implement?
> People doing things that we don't personally approve of?

None of those.  It wouldn't be much harder, but it may not be desirable.

> This makes it more like a hash table/dictionary than an array, which
> is a good thing in my view. (Registering "attribute #1001" for a
> particular use seems like too much of a "magic number". Better to give
> it a descriptive name.)

That is a valid alternative to numeric tagging.  One concern I would 
have is that 15,000 of these things will be flying at the client when 
you enter a sim.  It could be slow to process string keyed tags.


> The server would be completely ignorant of the tags, except for
> storing them (probably enforcing a data-size limit per prim) and
> passing them along to each client that sees the prim. It would be up
> to each client to a) pay attention to any particular attribute, b)
> verify that the data is proper, well-formed, not malicious, etc., and
> c) act in some way based on the attribute.

Yep.


> As far as accessing the attributes goes:
> 
> - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string
> label, string data)' would seem to be all that is needed. Maybe later,
> functions which accept a list of [label, data, label, data, ...] to
> get/set multiple attributes at once, for efficiency. Perhaps also a
> separate `llDeleteAttribute(string label)' function to delete the
> attribute entirely (instead of just making its data blank).

That sounds good to me for what you are trying to do.  I think you 
should write this up as a new wiki page and link it from mine as an 
alternative implementation, with different design goals.


> - from client code: similar functions to LSL, but with an additional
> function to set an attribute locally, without modifying the object on
> the server.

What does this serve?

> 
> - from the UI: assuming that you have permission to modify a prim, I
> see no reason why you shouldn't be able to edit its arbitrary
> attributes from the UI, like you edit its name, description, and other
> parameters. This could be written later, in terms of the client code
> functions mentioned above.

That's a lot of nastiness to show to the user.  Best leave it to LSL 
scripters to wrap it in something user friendly.  It's not 
unprecedented, there's no UI to create a particle system, for example.

> Perhaps it would also be useful to have "hidden" attributes, which are
> not visible to clients.  (This would be quite handy as persistent data
> storage for LSL scripts!)

I doubt LL wants this, or they would have done it already.  That was one 
of the reasons my proposal doesn't have a "Get" function, so that it 
can't be used for LSL data storage, and only used for the intended purpose.

-Jason