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

Jacek Antonelli jacek.antonelli at gmail.com
Tue Feb 27 15:16:22 PST 2007


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.

So, given that the for-testing-only design is admittedly unsuitable
for the purposes of for-use, and given that for-use is broader and
more useful, what reason is there to consider for-testing-only? What
are the concerns about for-use? Less secure? More work to implement?
People doing things that we don't personally approve of?

I wrote a blog post about "arbitrary prim attributes" some time ago.
(I am loathe to plug my own blog, so I won't link to it. I'm sure
Google can help you find it, if you want to.) To summarize what I said
there: SL could follow the route of XML, where each element can have
many tags, each with a label and a data string (e.g. foo="42 bar").
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.)

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

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

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

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!)

Any thoughts, comments, suggestions, etc.?

  - Jacek Antonelli


More information about the SLDev mailing list