Hello Jack,
Actually, there is one way to create something like a plugin.
As you may know, V2 uses HTML for some parts of interface, like Home Page. And,
V2 interface is skin-based, so, for example, you could add your tab to the
sidebar.
Than you could create some RIA interface (Flash/Silverlight), and connect it
with OpenSim region module, which should provide some kind of web service
endpoint.
I've tried this in my project, and it works. I've created a simple presentation
screen, controlled from a tab in viewer sidebar.
You could even send some information about user (like username), than, just for
example, track avatar position in world and change the RIA interfaces
dynamically - but in that case you have to use something like WCF double
binding.
The trouble is that the users have to install your customized skin for viewer.
It's not a problem in a local enterprise network (my case), but with HG and
public grids.... yes, it's a problem.
If you are interested, I could publish VS2010 template for region module with
WCF interface (very simple), and three parts of such "plugin" - modified XML's
for viewer skin, Silverlight application and OpenSim region module.
But, as it seems to me, it's really easy to create something like this without
my bugs in code :)
Vitaly
15.05.2011, 12:20, [email protected]:
> Send Opensim-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.berlios.de/mailman/listinfo/opensim-users
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-users digest..."
>
> Today's Topics:
>
> 1. plugin/extension/module system for viewers? (Cider Jack)
> 2. AJET special issue: Virtual Worlds in Tertiary Education -
> proposal deadline approaching (Lee, Mark)
> 3. Re: plugin/extension/module system for viewers? (DutchGlory)
> 4. Re: plugin/extension/module system for viewers? (Sean McNamara)
> 5. Traffic visualization (vehicles/ppl) showcase
> (Marcus Alexander Link)
> 6. Re: plugin/extension/module system for viewers? (Toni Alatalo)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 15 May 2011 14:22:11 +1200
> From: Cider Jack <[email protected]>;
> To: [email protected]
> Subject: [Opensim-users] plugin/extension/module system for viewers?
> Message-ID: <[email protected]>;
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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!)
> 2. Nobody has taken the time to implement it
> 3. A technical reason makes it impossible
> 4. SL's terms wouldn't allow the viewer to be used with SL (This
> sounds most likely to me)
>
> Is there something I'm missing?
>
> In regards to number four, it's probably primarily based on a
> combination of the dreaded CopyBot and the Emerald debacle. 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.
>
> Anyway, just pipe-dreaming here! :)
>
> Cheers,
> ~!CiderJack
>
> ------------------------------
>
> Message: 2
> Date: Sun, 15 May 2011 14:26:49 +1000
> From: "Lee, Mark" <[email protected]>;
> To: "[email protected]" <[email protected]>;
> Subject: [Opensim-users] AJET special issue: Virtual Worlds in
> Tertiary Education - proposal deadline approaching
> Message-ID:
> <3b889ee9152f28429040abdc2c606f2e08a9da0...@mail01.csumain.csu.edu.au>;
> Content-Type: text/plain; charset="us-ascii"
>
> Dear colleagues,
>
> (Apologies once again for cross posting.)
>
> This is a reminder that proposals in the form of extended abstracts for the
> special issue of AJET on virtual Worlds in tertiary education are due on
> Monday, May 23, 2011.
>
> For more information, please see the Call for Articles at
> http://ascilite.org.au/ajet/about/special-issues/virtual-worlds-2012.html .
>
> Queries and expressions of interest can be directed to the Guest Editors,
> Mark J.W. Lee, Barney Dalgarno and Helen Farley at
> [email protected].
>
> *** About AJET ***
> The Australasian Journal of Educational Technology (AJET) (ISSN: 1449-5554)
> is a refereed academic journal that publishes scholarly research and review
> articles in educational technology, ICT for education, online and e-learning,
> educational design, multimedia, computer-assisted learning, and related
> areas. AJET is the official publication of the Australasian Society for
> Computers in Learning in Tertiary Education (ascilite at
> http://www.ascilite.org.au/). The journal was published under the title
> Australian Journal of Educational Technology from 1985 to 2004, after which
> it was renamed to its current title. In 2008, AJET became an online-only
> journal, and since that time has prided itself on being an open access
> publication.
>
> AJET's current Thomson Reuters Impact Factor is 1.278. It ranked 27 out of
> 139 journals in the 'Education & Educational Research' category in the 2009
> ISI Journal Citation Reports, making it one of the highest ranking
> educational technology journals.
>
> Kind regards,
>
> Mark J.W. Lee
> Adjunct Senior Lecturer, School of Education, Charles Sturt University
> Adjunct Senior Lecturer, DEHub research institute, University of New England
>
> ------------------------------
>
> Message: 3
> Date: Sat, 14 May 2011 22:14:05 -0700 (PDT)
> From: DutchGlory <[email protected]>;
> To: [email protected]
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <[email protected]>;
> Content-Type: text/plain; charset=us-ascii
>
> YES, make a plug-in for viewing mesh objects..!!! no more SL mesh beta
> viewer...
>
> dutch
>
> -----
> ______________________________________________
> OpensimFan (twitter)
> MetalFan (OSGRID)
> Dutchlord (My Open Grid)
> --
> View this message in context:
> http://opensim-users.2152040.n2.nabble.com/plugin-extension-module-system-for-viewers-tp6364608p6364855.html
> Sent from the opensim-users mailing list archive at Nabble.com.
>
> ------------------------------
>
> Message: 4
> Date: Sun, 15 May 2011 02:02:06 -0400
> From: Sean McNamara <[email protected]>;
> To: [email protected]
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <[email protected]>;
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> On Sat, May 14, 2011 at 10:22 PM, Cider Jack <[email protected]>; 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
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>
> ------------------------------
>
> Message: 5
> Date: Sun, 15 May 2011 09:20:00 +0200
> From: Marcus Alexander Link <[email protected]>;
> To: [email protected]
> Subject: [Opensim-users] Traffic visualization (vehicles/ppl) showcase
> Message-ID: <[email protected]>;
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everyone,
>
> i am looking for a Traffic planning/Traffic visualization
> (vehicles/ppl) showcase.
> Would it make sense to use OpenSimulator for such a project, or is it
> just me - who want to use OpenSim as platform for everything ^^
>
> Thx,
> Marcus
>
> ------------------------------
>
> Message: 6
> Date: Sun, 15 May 2011 11:20:45 +0300
> From: Toni Alatalo <[email protected]>;
> To: [email protected]
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <[email protected]>;
> Content-Type: text/plain; charset=us-ascii
>
> On May 15, 2011, at 9:02 AM, Sean McNamara wrote:
>
>> On Sat, May 14, 2011 at 10:22 PM, Cider Jack <[email protected]>;
>> wrote:
>>> 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
>
> We did this by developing a modular viewer, Naali. It has a module system
> somewhat similar to Opensim, but in C++.
>
>>> 2. Nobody has taken the time to implement it
>> This seems the most likely alternative to me.
>
> It did take us a couple of years :)
>
>> 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
>
> Naali supports currently C++ modules, Python add-ons, but for custom
> functionality, most significantly Javascript which is loaded from the web.
>
> The support for interpreted languages was made exactly was this reason --
> dealing with native code addons is much more hairy.
>
> The C++ module system is still highly useful. For one, by using it for almost
> all functionality, many of the things are optional. For example the Bullet
> physics library, which is integrated in one module (yes, works on the viewer
> side too, which is often *very* useful). Also people sometimes need to do
> custom stuff in native code for special applications, which can be useful
> even if that is made in some special module that doesn't need to be
> distributed.
>
>> 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).
>
> We think we are close to freezing the first step of the API now, to declare
> it 1.0. It is documented in http://www.realxtend.org/doxygen/
>
> It still takes us at least some weeks anyway to make the last currently
> planned breaking changes. so now is a good time to give feedback if something
> seems wrong.
>
> This API is indeed similar to the W3C standardized DOM in web browser. In web
> browsers, the Javascript scope has things like 'document' and 'window'. In
> this virtual world browser, instead, there is 'scene' which has all the
> entities (prims on the opensim side) etc. And renderer which you can use for
> raycast etc.
>
>> 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.
>
> We believe a good way to advance standardization etc. is to implement stuff,
> so now there is a working implementation out, even in production use, so we
> can really evaluate and test all these problems.
>
> Security is certainly a huge deal. I did the basics to sandbox our JS API in
> December, to protect from basic attacks known from the browser land, but it
> certainly needs more review still. It is now made so that remotely loaded JS
> code shouldn't be able to get system access in any way.
>
> Prim support in Naali is in c++, actually predates really working Python or
> Javascript support. Possibly is best to remain in c++ too.
>
> But some quite central things, like avatars and cameras, are now ported from
> C++ to Javascript. No performance problems there, it's not like you have
> thousands of them around in your scene. Object editing has been in Python
> since the beginning (was the original benchmark for the scripting API: i
> figured that if doing basic object editing is possible in a script, then also
> making games is easily possible).
>
> Also in the current Tundra 1.0.6 release, the whole UI (which looks like a
> web browser) is implemented in Javascript now. Naali 0.4 still has a largely
> c++ written UI (with some Python tools).
>
>> 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
>
> This is exactly how we've done it in Naali too.
>
> The other guys originally used GTK for first UI tests, just to get debug info
> of the from-the-scratch written LLUDP implementation (Naali is BSD style
> apache licensed, no Linden code, respects the Opensim contributions policy).
> I was experimenting with adding Python support just manually first, to better
> know what kind of a tool would need for the job.
>
> Then we decided to use QT for UI, just to get something for good 2d widgets.
> Soon I learned about qtscript (and the similar pythonqt) which indeed use the
> qobject metadata mechanism for automatic exposing of c++ things to scripting,
> so we went with that and have during the past 1,5years ported all the
> modules, entity-components etc. to QObjects. So the same API works for c++,
> py and js. Lua could be easily added in a new c++ module, using QtLua. Then
> for the security reasons for remotely loaded code, only selected parts are
> available in the context for those (and new contexts are easy to make for
> different purposes, e.g. to support LSL style where a script can only see the
> own object).
>
> BTW: the JS system is not (only) a plugin / addon system, but it is also the
> way to make applications. It is identical to how web works as an app
> platform: besides getting static data from the servers, the viewer downloads
> also executable code as a part of the service. This way any sim can implement
> whatever kind of client side functionality, e.g. UI dialogs, mouse&keyboard
> handling etc. it wants.
>
> Some examples:
> the current free camera:
> https://github.com/realXtend/naali/blob/tundra/bin/jsmodules/camera/freelookcamera.js
> This default camera is instanciated by startup/cameraapplication.js so is
> always there by default.
>
> client side chat UI:
> https://github.com/realXtend/naali/blob/tundra/bin/scenes/ChatApplication/ChatApplication.js#L237
> .
> This is typically loaded from the server, if the service you connect to has
> decided to have a chat feature.
>
>> 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
>
> You could show Linden our code, I don't know if they've looked at it :)
>
> But yah, I've bugged the Imprudence devs about this periodically .. well more
> late last year, when they said the time was immature as they had a lot to do
> with basics, but they hoped to get to this later.
>
> I guess there's two options for those who want this: a) try to do this on the
> SLviewer base b) join the Naali effort, where it's already made, to help
> getting missing SL features (or whatever features you need, that you
> typically use with Opensim) there. One benefit of Naali is that it's a normal
> open source project, like Opensim, not controlled by any single company, and
> has a liberal license compatible with Opensimulator itself. But sure SLviewer
> has a lot of nice functionality, is quite interesting if we'd get this in
> e.g. Imprudence too.
>
>> Sean
>
> ~Toni
>
>>> Anyway, just pipe-dreaming here! :)
>
> No pipe dreaming, it is already the reality, and quite normal (web browsers
> have had this for long, so why not vw viewers).
>
>>> Cheers,
>>> ~!CiderJack
>>> _______________________________________________
>>> Opensim-users mailing list
>>> [email protected]
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> _______________________________________________
>> Opensim-users mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>
> ------------------------------
>
> _______________________________________________
> Opensim-users mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
> End of Opensim-users Digest, Vol 45, Issue 32
> *********************************************
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
