[Opensim-dev] Thoughts on Scripting
Diva Canto
diva at metaverseink.com
Sun Sep 7 14:21:21 UTC 2008
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
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080907/1aa741da/attachment-0001.html>
More information about the Opensim-dev
mailing list