[Opensim-users] plugin/extension/module system for viewers?

Sun May 15 06:02:06 UTC 2011

Hi,

On Sat, May 14, 2011 at 10:22 PM, Cider Jack <ciderjack.vw at gmail.com> wrote:
> I know this is related to viewers rather than OpenSim directly and as
> such may be completely inappropriate for this list, so please feel
> free to ignore this!
>
> This has been on my mind for a few years now and I thought I would
> just go ahead throw it out there -- Why hasn't there been some sort of
> plugin/module system developed for Viewers? Something along the lines
> of Firefox or Google Chrome's add-on/extension system comes to mind. I
> would expect it to be simple to implement, and I can imagine all sorts
> of community created tools for builders, avatar designers, scripters,
> machinamists, terraforming, etc. that could greatly extend viewer
> functionality & customization! I can think of only four reasons this
> hasn't happened:
>
> 1. Nobody building viewers has thought of it (I don't believe this!)

I myself have never thought of it before, but I wouldn't be surprised
if someone else has, indeed.

> 2. Nobody has taken the time to implement it

This seems the most likely alternative to me.

> 3. A technical reason makes it impossible

Nah, it's not impossible. Of course you'd have to use a dynamically
interpreted language for plugins, because the viewer is written in
C++, which compiles to native code. Distributing plugins as native
code is dangerous for two reasons: one, it's impossible to sandbox or
control what native code can do, and two, you can't possibly
distribute a plugin to be binary-compatible with every platform that
SL runs on. As soon as you claim that you have built a native plugin
that covers all the platforms, I will find a Linux distro where your
plugin doesn't link, or run SL on Solaris or BSD. So it has to be
platform-independent.

So you could use JavaScript like Chrome/Firefox plugins do, or you
could pick up one of the many readily-available scripting languages
out there, like Lua, or you could build in something else entirely
(Java and C# are conceivably possible, but would add system
dependencies to the viewer: you'd have to have the Java runtime or a
.NET runtime or Mono installed, as the case may be).

Despite it being possible rather than impossible, I can definitely say
that it wouldn't be, as you say, "easy". Integrating a dynamically
interpreted scripting language and then designing a stable plugin API
is no walk in the park; just ask the developers who work on Firefox or
Chrome's plugin architecture. The biggest challenge would come in
supporting whatever plugin API you design over the lifetime of the
viewer, or properly versioning the plugin API in a way that doesn't
break too many plugins too often (Firefox does this).

> 4. SL's terms wouldn't allow the viewer to be used with SL (This
> sounds most likely to me)

Whether or not Linden Lab would find viewer plugins to be
objectionable is completely orthogonal to whether they should be
implemented. SL is just one grid; the fact that you're posting on the
opensim ML indicates you know that other grids exist and they're much
less strict. And no, I don't care a lick if InWorldz wants to lock
down peoples' viewers. All the other OpenSim grids I'm aware of are
very liberal about what viewers you're allowed to run, and what you're
allowed to do with them. Take OSgrid and 3rd rock for instance. There
are plenty of grids out there that will accept a viewer almost
completely regardless of what features that viewer has ( provided that
it doesn't attempt to attack the grid in some malicious way ). Thus we
don't need to give a crap about what the corporate grids want in order
to implement something. The software is open source.

And besides that, I don't think that LL would have a fit about it. You
seem to be under the misconception that third party viewers are
carefully scrutinized and/or reviewed before they are allowed on the
SL grid. That's not the case. There are a few rules you have to follow
to host a third-party viewer, but you can more or less do what you
want with the code, and you don't have to get LL's permission. You
just can't break any laws or violate the terms of service. Shipping
plugins hardly does that.

>
> Is there something I'm missing?

The challenging part of this is to engineer a plugins API that is
useful, but not so expansive or general that it would (a) pose a
security risk to the user (stealing their password etc), or (b) allow
the plugin to do crazy things like provide mesh support (yes, I'm
replying to your message DutchGlory), which could never gain any
semblance of performance implemented in an interpreted scripting
language.

>
> In regards to number four, it's probably primarily based on a
> combination of the dreaded CopyBot and the Emerald debacle.

No. If plugins are done properly, it won't be possible to do something
like a copybot, and the KDU thing will be completely irrelevant. You
have to sandbox plugins and implement the API in a way that nothing
inherently dangerous can happen. This is why you can install most
plugins on Google Chrome or Firefox without worry that it will steal
your passwords -- at least, not without your explicit consent. You
have to find the balance between flexibility and security.

It's NOT an easy engineering problem, but it is feasible.

> Perhaps a
> central repository where the code can be reviewed before release
> (again, like Firefox or Google Chrome) could prevent these sorts of
> abuses. Additionally I suspect the viewer would only need a couple of
> lines of code to load the plugins, and leaving the code out wouldn't
> affect the viewer functionality, so two versions of the viewer could
> be released - an extendable version, and the locked-down SL version,
> which isolationist grids like InWorldz may insist on as well.

If the plugin architecture is implemented with proper sandboxing, the
mainline LL viewer might even pick it up if it's particularly
well-done. But LL has a history of not accepting large feature
contributions from the community at large, so don't count on them
picking it up. That said, if it's done right, I bet at least
Imprudence, Phoenix and perhaps Hippo might pick it up.

If I were to lay out a possible approach for this, I'd say we could
start with QtScript or Lua integration into the viewer. QtScript
provides JavaScript support, and is specifically designed to help you
create an extension language for your app; and, it's written in C++ (a
huge plus considering the rest of the viewer is). The license is
compatible with the license of the viewer as long as we don't have to
make modifications to Qt itself.

But now that I've strayed completely off the topic of this list, I'd
say that you should bring this up with the Imprudence developers for
starters. Don't go to Linden Lab because they will say "show us the
code or be quiet", essentially. They have their own feature roadmap
that operates more or less independently of what the community wants,
but since the viewer is open source, we've got the power to implement
anything we want to.

Sean

>
> Anyway, just pipe-dreaming here! :)
>
> Cheers,
> ~!CiderJack
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>