[sldev] LSL initiated Prim metadata was Re: Plugin architecture
gigstaggart at gmail.com
Tue Feb 27 15:36:57 PST 2007
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
>> 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.
> 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.
> 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.
More information about the SLDev