[Opensim-dev] Thoughts on Scripting

Sun Sep 7 14:52:58 UTC 2008

Isn't there a difference in the accessibility of the external API vs an in
world API? Isn't use of the external API limited to those that are running
the sim while the in world API is available to anyone in world?

I also like to think about the "content creator" role and how it differs
from the "developer" role. The "content creator" uses powerful in-world
building tools to create stuff. The "developer" would extend the tools
available to "content creator" by adding external modules to the region.

I also see analogies with other 3D content creation tools. Some of
them offer a plugin architecture for extending the tool itself as well as
sort of scripting tool for working within the tool.

I think both sets of APIs are needed. Perhaps Stefpan's idea of generating a
assembly that captures the content creator's work is a good way to allow the
in world content creator to access the functionality of the external APIs.

Also, as I mentioned to Stefan, I think there are some things we can do
sooner rather than later to improve the in world building experience. We
don't have to wait for a new client.

  == Mike ==

On Sun, Sep 7, 2008 at 6:06 AM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080907/5d5a828f/attachment-0001.html>