[Opensim-users] Opensim-users Digest, Vol 45, Issue 32 (Vitaly Chashin)
Виталий Фицнер
wchf at yandex.ru
Sun May 15 15:27:51 UTC 2011
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, opensim-users-request at lists.berlios.de:
> Send Opensim-users mailing list submissions to
> opensim-users at lists.berlios.de
>
> 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
> opensim-users-request at lists.berlios.de
>
> You can reach the person managing the list at
> opensim-users-owner at lists.berlios.de
>
> 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 <ciderjack.vw at gmail.com>;
> To: opensim-users at lists.berlios.de
> Subject: [Opensim-users] plugin/extension/module system for viewers?
> Message-ID: <BANLkTimecFs5LjnEfMHcFOrJpTGjuovunQ at mail.gmail.com>;
> 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" <malee at csu.edu.au>;
> To: "opensim-users at lists.berlios.de" <opensim-users at lists.berlios.de>;
> Subject: [Opensim-users] AJET special issue: Virtual Worlds in
> Tertiary Education - proposal deadline approaching
> Message-ID:
> <3B889EE9152F28429040ABDC2C606F2E08A9DA0476 at 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 ajet.virtualworlds at gmail.com.
>
> *** 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 <info at verwijs-pc.nl>;
> To: opensim-users at lists.berlios.de
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <1305436444993-6364855.post at n2.nabble.com>;
> 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 <smcnam at gmail.com>;
> To: opensim-users at lists.berlios.de
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <BANLkTiktN2VxuiqGsr=yRf59JpCifc3EaA at mail.gmail.com>;
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
> ------------------------------
>
> Message: 5
> Date: Sun, 15 May 2011 09:20:00 +0200
> From: Marcus Alexander Link <manupool at gmail.com>;
> To: opensim-users at lists.berlios.de
> Subject: [Opensim-users] Traffic visualization (vehicles/ppl) showcase
> Message-ID: <BANLkTikH=y2+LyeJcZ8U_n58cxAEJCerNQ at mail.gmail.com>;
> 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 <toni at playsign.net>;
> To: opensim-users at lists.berlios.de
> Subject: Re: [Opensim-users] plugin/extension/module system for
> viewers?
> Message-ID: <F7B06E15-306F-4A35-A452-39FEC23BDD47 at playsign.net>;
> 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 <ciderjack.vw at gmail.com>; 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
>>> Opensim-users at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>
> ------------------------------
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
> End of Opensim-users Digest, Vol 45, Issue 32
> *********************************************
More information about the Opensim-users
mailing list