[Opensim-dev] Thoughts on Scripting

Sun Sep 7 15:46:37 UTC 2008

Diva, that way of laying things out helps me a lot. Yes, I agree that it is
a continuum. The lines certainly do get blurry.

 As I'm just an enthusiastic newbie new to all this OpenSim stuff, I have no
idea how it can all come together. But it sure is fun thinking about it
isn't it. :-)
I think one of the cool things about the managed code platform is that it
makes blurring the lines between data and code easier, especially with
things like the DLR.

I wonder how such things could be used to build a single set of apis that
work both in and out of the world?

  == Mike ==

On Sun, Sep 7, 2008 at 8:21 AM, Diva Canto <diva at metaverseink.com> wrote:

>
> Many people have said this already, it's really hard to draw the line of
> what to put where. There are really 3 kinds of module *flavours*, even
> though they all use the exact same API: (1) insfrastructure, like the sun
> module; (2) middleware, like the the IRC bridge and the data snapshot for
> search; and (3) applications, like a traffic simulation app. These are
> really flavours, there's not a hard distinction. Infrastructure means,
> roughly, "well, it does the same thing as you see in Second Life."
> Middleware means, roughly, "look out, this feels different from Second
> Life." And Applications means, roughly," this is what you could do with
> scripting, eventually. "
>
> So maybe there should be:
>
> OpenSim.Modules.Infrastructure
> OpenSim.Modules.Middleware
> OpenSim.Modules.AppExamples
>
> where the modules in Infrastructure would be on by default, and the others
> would be off by default. Obviously, there can be a huge amount of examples,
> but you would want to keep the number here down to just a dozen or so to get
> people going.
>
> Anyway, my 0.02 on this. I'm sure you'll know what to do.
>
>
> Stefan Andersson wrote:
>
> I just realized we have a REALLY simple 'Planetarium' module in Tribal Net
> that just makes some aptly named objects rotate around a similarly aptly
> named center object. That could serve as a really simple code example as
> well.. (It's quite hard coded atmo, just using it as a nice eye-candy
> watchdog for my region)
>
> Where should I put that, in the core as another example, or on the forge,
> or somewhere else?
>
> Should we even have an 'examples' or 'API' branch in the core svn, so
> people don't have to have several accounts to upload/download that kind of
> things? I would love for some noob/intermediate to expand on the module. :D
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
> Join the 3d web revolution : http://tribalnet.se/
>
>
>
>
> ------------------------------
>
> Date: Sun, 7 Sep 2008 07:21:21 -0700
> From: diva at metaverseink.com
> To: opensim-dev at lists.berlios.deI have a really simple
> Subject: Re: [Opensim-dev] Thoughts on Scripting
>
> Good point -- lots and lots of examples more. But I think this is the
> reason why people get the idea that the OpenSim API is "just" for extending
> OpenSim, and not for developing applications... :-) The vast majority of
> examples of using this API has the feel of server extensions. (Technically,
> especially using OO libs, the difference between extension and use is vague;
> but psychologically, people have a hard time seeing, say, the Sun control
> module as an "application")
>
>
> Teravus Ovares wrote:
>
> I also thought it was prudent to mention that many flagship features are
> implemented in the OpenSim API as a region module.
>
> Several notables;
> Friends Module
> Instant Messaging Module
> Sun control Module
> Asset Download module
> Xfer Module
> regular positional based chat module
> IRC Bridge chat module
> Map tile module
> ..    The list goes on..
> ..    and on...
> ..    and on..
>
> Best Regards
>
> Teravus
>
>
> On 9/7/08, *Diva Canto* <diva at metaverseink.com> wrote:
>
> Mike Deem wrote:
>
>  Thanks Crista.
>
> I think there are two separate application models at work here.
>
> What you describe is the API for extending the OpenSim itself. I'm sure
> I'll have fun experimenting with it in the coming weeks.
>
> This is a common misunderstanding. The OpenSim API is an API for extending
> OpenSim, yes; as well as for *using* OpenSim: "rezzing" objects inworld,
> linking them, unlinking them, moving them around, copying them, creating
> agents, giving them an appearance, moving them around, talking to agents,
> listening to them, etc etc etc -- everything you do with the SL viewer and
> with libsl-based clients (and more) can be done programatically on the
> backend using C#, dlls and the whole 9 yards, and bypassing inworld
> scripting altogether. I could, for example, give you my DLL that implements
> traffic in regions, and it will work out of the box in your regions after
> some initial manual setup for resources -- that's the closest to an
> "application" you can get for the time being. I will make that available one
> of these days as an example of developing OpenSim applications.
>
>   However, what I'm trying to understand are the kinds of features that
> make creating large and complex things in world easier. Usually you don't
> think of building and scripting in world as creating an application, but
> isn't that pretty much what it is? At least I find that thinking of it in
> those terms helps me start think about how to make the task of building
> complex things easier.
>
> Yes, applications is a good name. OpenSim allows you program them with
> backend modules. For large, complex things it's the best way to go. The idea
> of creating applications with inworld scripting is really cute, but only
> takes you so far, because the object model exposed to scripts by the Linden
> viewer is very limiting. What Stefan is talking about is way ahead; before
> going wild with imagining other clients, I think it's worth looking at what
> is already there.
>
> I really encourage you and everyone to take a look at the OpenSim API. For
> now, start with the SimpleExample code, even if it doesn't work. (I heard
> that in some releases it is broken) Don't think of this API as "just" a way
> to extend OpenSim.
>
> Have fun!
>
>   For example, it should be possible to link a set of prims, duplicate
> that set many times, and then make a change to a prim in the set and have
> that change replicated, automatically, to all the duplicates. Similarly, it
> should be possible to create a library of script functions that can be
> used by many scripts, without manually duplicating the script code over and
> over. You can think of these things as part of an app model that supports
> reusable components, something analogous to an assembly. Now you can start
> thinking about how you would "reference" such a component for your build or
> how you would distribute an updated version of the component.
>
> I wanted to know how others thought about the current "in world"
> application model and how it might be evolved. Is any work going on in that
> area?
>
>   == Mike ==
>
> On Sat, Sep 6, 2008 at 7:19 PM, Diva Canto <diva at metaverseink.com> wrote:
>
> Hi Mike,
>
> OpenSim has a rudimentary application model, or even two: the one I'm most
> familiar with are the region modules, and I think there's another module
> system. They allow you to develop applications for the OpenSim API.
> Developing for this API achieves everything you talk about -- or, ahem, it
> will, once a few rough edges are taken care of.
>
> There's practically no documentation about this API, and about application
> development with OpenSim, so at this point almost no one knows about it.
> This is because both the API and the module systems are still changing. You
> have to download the code and bravely browse through it. In any case, the
> module system(s) in OpenSim is still not as sophisticated as, say, a Tomcat
> webapp (there are no resources, for example), but it is the beginning of
> what you are looking for.
>
> Crista
>
>
> Mike Deem wrote:
>
>   I've got a few thoughts about scripting and I would like your feedback.
>
> But first, a bit of an introduction. I'm a professional software developer
> with years of experience working on all kinds of distributed applications. I
> became a SL resident, scripter, and builder in early 2006. I'm just
> beginning to get involved with OpenSim. This is a hobby for me, it is
> unrelated to my work.
>
> For a while I've been thinking about "application models" for virtual
> worlds. By "application model" I mean something that involves more than
> simply scripting.
>
> A traditional application is a package of application code, shared
> libraries, resources like images, etc. A platform's application model
> defines the structure of these packages as well as things like the security
> model, installation services, etc. To the user, an application represents a
> consistent self-contained "user experience," usually with a specific
> purpose.
>
> Of particular interest to me is the model for applications built *inside*a virtual world.
>
> A build of any level of complexity could be thought of as an application.
> For example: a building with door and window scripts, an attachment with
> configuration scripts, a vehicle, a stage with programed special effects for
> a product presentation, etc.
>
> SL offers a very rudimentary application model. You can put copies of
> scripts in prims and you can link a limited number of prims together. The
> platform also provides a security model and a number of other services.
>
> However, the SL application model is missing a bunch of things. For example
> we need a hierarchical prim model that supports any number of prims and at
> region scale, a way to share and reuse script libraries, a way to update
> things after they have been sold, given, or copied, etc.
>
> As the complexity of builds increase, the missing features become quite
> restrictive. This limits the ability of content creators to produce
> compelling user experiences. That limits the adoption of the platform for
> commercial purposes.
>
> In addition, the SL script execution model is complex to implement
> and requires a lot of computing resources. Specifically, treating global
> script execution state as a persistent data store is very problematic.
>
> I think we need something better. But I also think that making something
> that is really better could require moving away from the SL model in some
> fundamental ways.
>
> What do you think?
>
>   == Mike ==
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080907/e969262a/attachment-0001.html>