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

[Jesse Nesbitt]

I'd also like to point out that LL already has a packet called
ObjectExtraParams in the message template, so it seems that they're
already possibly working toward letting us embed metadata.

Also, Argent, prim parameters are sent to the client as an
ObjectUpdate packet, with strongly-typed variables, not stored/sent as
LSL lists.


On 2/27/07, Jason Giglio <gigstaggart at gmail.com> wrote:
> 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
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>


-- 
--Jesse