[Opensim-dev] Thoughts on Scripting

Sun Sep 7 15:21:55 UTC 2008

Stefan, that stuff is really cool. Very much like what I've been imagining.
Thanks for pointing me to it!

  == Mike ==

On Sun, Sep 7, 2008 at 8:06 AM, Stefan Andersson <stefan at tribalmedia.se>wrote:

> Mike,
>
> great thinking,
>
> and definitively; as I was trying to convey, we at Tribal have, since
> square one, tried to figure out how to create tomorrows architecture already
> with what we have today. Nothing conclusive so far, but you might want to
> check out
>
> http://lbsa71.net/category/tribal-media/tribal-one/
>
> for a series of (rather bad quality) youtube vids of some concepts we
> implemented some time ago - including a web api that would not only
> externalize interactivity, but also delegate the very creation of the
> in-world content to web services. Especially note the web pane that is used
> to interact 'around' objects.
>
> Diva just showed us a couple of screen shots where she's doing the very
> thing you propose, but from an app point, not from an generic object point.
>
> I don't believe these things are as far into the future as you might
> believe. There's a lot of really far-out things that can be done already
> with the current platform.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
> Join the 3d web revolution : http://tribalnet.se/
>
>
>
>
> ------------------------------
>
> Date: Sun, 7 Sep 2008 07:52:40 -0700
>
> From: mike at maimedleech.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Thoughts on Scripting
>
>
>  I've also been thinking about things like global scripts and external
> script servers. External script servers would solve some of the script state
> serialization issues. Instead of moving a running script from one region to
> another, it just keeps running on it's server.
>
> But what got me excited recently was the realization that we may not need
> new client functionality to add in world building features. Would something
> like the following work?
>
> Most clients have an embedded web browser. The server can request that the
> client open the browser on a specific URL, right? that means the server can
> provide it's own UI for things, it isn't limited to just the UI the client
> has implemented.
>
> For example, the server could show a tree of hierarchically linked prims
> and other objects. When you select one, you can see and change properties on
> that object that the client doesn't know about.
>
> The server can also use tricks like locking and unlocking prims and
> generating "bounding box" prims around grouped objects, allowing them to be
> scaled, rotated, etc.
>
> Granted it isn't perfect. Keeping the browser state and the viewer state in
> sync will be a challenge. But it is a starting point.
>
> If done right, the extended backend functionally would be expected as
> services that a client could call. That way you can start without any new
> client features, but the clients can add better features over time.
>
>   == Mike ==
>
> On Sat, Sep 6, 2008 at 11:51 PM, Stefan Andersson <stefan at tribalmedia.se>wrote:
>
> At the moment, it seems we have two main strands of developers; the
> 'scripters' and the 'appers' - those using the in-world (SL-based)
> programming model and the ones using the module API's to create region-wide
> and integrations behaviours.
>
> Of course, there's several ideas of where to take OpenSim behaviour
> customization, but so far, we haven't discussed it much.
>
> Although, the scripting engine model allows us to use an array of languages
> for scripting, and several of them probably gives you the option to do those
> things you list.
>
> I guess the big revolution comes the day we drop our SL-client-centric view
> of building and scripting, and begin to see external tools to compose
> behaviours and content, where you can add contextual points that simply
> aren't there in the SL viewer today. As, for example, region-wide global
> scripts and libraries - there simply aren't anywhere to place those in th
> SL-centric model.
>
> We at Tribal have been toying with a multitude of ways to get round this
> (like having region nodes in the inventory, with objects that are local to
> the region) so there's definitively room for invention and experimentation.
>
> One thing I would like to see somebody do, is to have prim scripts being
> compiled into a c# assembly; ie, something along the line that all scripts
> that are referenced from within a prim becomes a compiled whole, which would
> let scripts reference resources in other scripts - and as mentioned, in
> library nodes. If the actual Prim would be compiled into a referencable
> (probably marshalled) entity too, that would open truly amazing
> opportunities.
>
> Another interesting Tedd concept that's unfortunately haven't been worked
> on is the scriptserver, where behaviours are collected and externalized to a
> central process that could govern several objects in several region
> processes.
>
> Just some cents,
> Stefan Andersson
> Tribal Media AB
>
> Join the 3d web revolution : http://tribalnet.se/
>
>
>
>
> ------------------------------
>
> Date: Sat, 6 Sep 2008 21:56:08 -0700
> From: mike at maimedleech.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Thoughts on Scripting
>
>
>
>  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.
>
> 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.
>
> 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 list
> 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/cf6ead7a/attachment-0001.html>