Lua's been implemented in a TPV successfully, meaning client-side
scripting is definitely possible. The only problem is that the viewer
was never intended to have a scripting engine built-in, so lots of
hacking on the backend to expose useful methods to the scripting engine
is required. The threading is also a mess right now.
Another consideration is what restrictions LL will want on these
plugins. I've already gone ahead and assumed that LL doesn't want
scripts to have raw access to the messaging system, to avoid having
malicious plugins sending disruptive or dangerous packets to the
network. I've also placed a policy on viewer development where access
to economic functions must be approved by the user (via a warning dialog
or a settings checkbox), and TPV policies (such as checking for creator
permissions before accessing an object) have also been implemented.
Rob Nelson
Luna Viewer
On 9/24/2010 5:43 PM, Brandon Husbands wrote:
Yikes... I misread your post. LOL There are plenty on this list that
try to close threads with links to past discussions. LOL my bad.. Ty
for the links.
On Fri, Sep 24, 2010 at 5:54 PM, Ricky <kf6...@gmail.com
<mailto:kf6...@gmail.com>> wrote:
Please read these threads for the discussions we had on the types and
limits of various plugin schemes:
* "Client-side scripting in Snowglobe" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000088.html
* "Consensus? was: Client-side scripting in Snowglobe" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
* "Client Plugin System Design" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html
There are many useful ideas and documented pitfalls to avoid. With
due consideration of these conversations many of the expected
issues/fears can be "headed off at the pass" you might say.
Ricky
Cron Stardust
On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands
<xot...@gmail.com <mailto:xot...@gmail.com>> wrote:
> I have already started work on a plugin system with embeded
mono. Which you
> expose methods to the api.. This allows anyone to use any CLI
language to
> create plugins.
>
> I can post more info on this later. A tad bit busy at the moment.
>
> On Fri, Sep 24, 2010 at 4:20 PM, malachi <mala...@tamzap.com
<mailto:mala...@tamzap.com>> wrote:
>>
>> i for one particularly love this idea. i think there should be
a way for
>> the default LL issued viewer to be a plain jane for every user
client. but
>> allow third party devs to create plugins that do whatever they
want. the
>> idea of the radar and ao are amazing. but dont stop there.
there are tons
>> of things that average users DO NOT use in the client already.
LL could
>> simply remove those items and offer them as plugins. i am for
this idea of
>> modularity 100%. my only question is where do we start?
>>
>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c <miss_c...@yahoo.com
<mailto:miss_c...@yahoo.com>> wrote:
>>
>> > Would it be a plausible feature in the future to have the
code accept
>> > third
>> > party plug-ins instead of creating whole new viewers? Then
have a Third
>> > party
>> > directory approved plug-in list. As I mentioned before, my
husband is
>> > making an
>> > external installer for people that may have difficulty
installing skins
>> > into the
>> > new viewer, this will be a directory that all skin designers
can add
>> > their skins
>> > to. Wouldn't it be better to have a RLV plug in or an AO
plug in, or a
>> > radar
>> > plugin that displays distance, then have to add all that to each
>> > viewer? I do
>> > realize that there may be some things that Linden Lab might
not want to
>> > add to
>> > their code but if its switched to a plug in system, people
can pick and
>> > choose
>> > which additional features they prefer without having whats
considered
>> > competing
>> > iewers.
>> >
>> > TY
>> >
>> > Miss
>> >
>> >
>> >
>>
>>
>> --
>> Using Opera's revolutionary e-mail client:
http://www.opera.com/mail/
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>
>
>
> --
>
-------------------------------------------------------------------------------------------------------------------------------
> This email is a private and confidential communication. Any use
of email may
> be subject to the laws and regulations of the United States. You
may not
> Repost, Distribute nor reproduce any content of this message.
>
-------------------------------------------------------------------------------------------------------------------------------
>
-------------------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
--
-------------------------------------------------------------------------------------------------------------------------------
This email is a private and confidential communication. Any use of
email may be subject to the laws and regulations of the United States.
You may not Repost, Distribute nor reproduce any content of this message.
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
