[Opensim-dev] Thoughts on Scripting
Diva Canto
diva at metaverseink.com
Sun Sep 7 15:21:25 UTC 2008
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
> <mailto: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
> <mailto: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 <mailto: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 list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://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/9cb43ab4/attachment-0001.html>
More information about the Opensim-dev
mailing list