Re: [ogpx] Limits to interoperability of scripted objects

[Morgaine <[e-mail]>]

On Tue, Oct 27, 2009 at 4:51 PM, Joshua Bell <[e-mail]> wrote:

>
> * Your (3) (common scripting environment) is intriguing. Sun's Project
> Wonderland uses Java (obviously...) as the common format, and (vastly
> simplifying) all objects in the VW are Java objects. I'd love to learn more
> from them about the challenges and successes. That said, at a protocol
> level, I don't think we'd ever dictate a common environment, so going down
> this road might turn into a de-facto common case of the content negotiation
> (just as the Web technically allows for client-side scripting languages
> other than Javascript, although they are used incredibly infrequently in
> practice).
>
> * Client-side scripts are also intriguing. If I think about what this means
> in practice, it's that the client is able to manipulate the state of objects
> in-world. Well, duh - that's what editing and appearance tools do! So...
> that capability (pun intended!) is a requirement at the protocol level,
> although I don't think we've even brushed on how to define it yet. It would
> be intriguing if the protocol were such that the client could expose a
> DOM-like view of the world to local scripts to observe and mutate.
>
>
>  I like both of those ideas.  I wonder if we could support them both in
principle with minimal effort by providing a generic hook using script
metadata.  Let some attribute select between "region" (for scripts running
in the current region as in SL), "avatar" (for HUD scripts that run in-world
but don't need region events so they can be run in a separate load-balaced
server pool), "home" (for scripts that always run in the agent's home
region), and "client" (for client-side scripts or plugins).  Further
attributes could specify the language and maybe a startup argument list
too.  (These are just random ideas, not cohesive.)

Thinking about the scripting languages themselves, presumably nobody would
argue in favour of turning LSL into an interop standard given the poverty of
its syntax, but even worse is the tortuous and complex semantic of its
system calls which would be very problematic to standardize, or maybe
impossible.  The SL scripting environment has evolved in a way that isn't
conducive to portability, not only because the implementation is closed and
quite unique, but also because it's tied fairly strongly to a proprietary
physics engine for events/simulation and to a rather esoteric communications
model.  These things conspire to make standardising around the SL scripting
mechanism very unlikely.  This gives us a solution to cross off the list,
but unfortunately doesn't offer us anything in its place.

Being realistic, forcing language commonality at this early stage is just
not going to happen, so we might as well lubricate the protocol machinery to
allow multiple scripting systems to be supported.  Eventually a de-facto
standard will emerge as happened with Javascript.  Let people with more
spare time than we have sort it out, and may the best idea win. :-)

As lubrication, I think we should provide at the very least some generic and
extensible metadata hooks in the protocol for this, otherwise the spec will
be modified incompatibly outside of the standard to support the diverse
scripting requirements of worlds, and then interop suffers.


Morgaine.





=========================================

On Tue, Oct 27, 2009 at 4:51 PM, Joshua Bell <[e-mail]> wrote:

> Good analysis as usual, Morgaine!
>
>
> On Mon, Oct 26, 2009 at 10:15 PM, Morgaine <[e-mail]
> > wrote:
>
>> Being pragmatic about the situation, if we wish to see interop of
>> scripting in the relatively near future, we need to find an approach that is
>> inherently interoperable.  Here are some ideas that might be relevant to
>> this end (these are alternatives, they don't all apply simultaneously):
>>
>>
>>    1. Make script state transfer a deployment option:  both source and
>>    destination regions have to allow script state transfer for it to happen.
>>    2. Worlds running different scripting engine implementations do not
>>    transfer state and hence scripts are initialized on teleport.
>>    3. Define a common scripting language and virtual machine environment
>>    --- ie. a web-like Javascript approach but for regions.
>>    4. If script state continuity is desired on teleports between worlds
>>    running different script engines, let such scripts run client-side.
>>
>>
> A few thoughts on the above:
>
> * Even though the Web appears to have given up on content negotiation over
> HTTP, I'm still a fan and I think cross-system interop like this is a good
> place for it. During Region-to-Region state transfer, you could imagine the
> destination region advertising the script state types it accepts
> (vendor/com.lindenlab.secondlife.lsl2mono, vendor/org.opensim.dotnetengine,
> ...), and the source region delivering one tagged with appropriate type. I
> would imagine we'll need similar logic for static content as well - articles
> of clothing could have have "prim" or "mesh" based versions, and regions may
> prefer one type to another. (Although it would be more likely to have both
> available on the region, and have content negotiation occur on the
> region->viewer resource transfer.)
>
> * Given the desire for "tourist" models (using the term loosely - I "live"
> on my home grid, but like to visit other grids), it doesn't seem like
> there's a one-size-fits-all approach (since region-to-region teleports in my
> home grid and region-to-region teleports between grids utilize the same
> protocol). So... this is definitely part of the protocol's mandate to sort
> out.
>
> * Combining the above two points, it implies that attachments will have to
> cope with moving from areas where they have scripts running to scripts not
> running (if the code/state is not compatible with the hosting region).
> Fortunately, we have precedent for that. :)
>
> * Infinity and I very briefly hand-waved about whether "portable" content
> (primarily, attachments to avatars) should even be executed within the
> region domain. Perhaps they should be executing in the agent domain? That's
> a radical departure from how SL or OpenSim work today. (If you squint your
> eyes and partition the current services, at least.) - at any rate, today
> there is no script execution outside of a region. It's an intriguing idea,
> but by no means complete - how such fine grained state might be updated
> between domains, for example. Vehicles come to mind as another case, and
> those have no clear "home base" for script execution. I suspect this is not
> tractable for the first iteration of VWRAP, but I don't want to dismiss it.
>
> * Your (3) (common scripting environment) is intriguing. Sun's Project
> Wonderland uses Java (obviously...) as the common format, and (vastly
> simplifying) all objects in the VW are Java objects. I'd love to learn more
> from them about the challenges and successes. That said, at a protocol
> level, I don't think we'd ever dictate a common environment, so going down
> this road might turn into a de-facto common case of the content negotiation
> (just as the Web technically allows for client-side scripting languages
> other than Javascript, although they are used incredibly infrequently in
> practice).
>
> * Client-side scripts are also intriguing. If I think about what this means
> in practice, it's that the client is able to manipulate the state of objects
> in-world. Well, duh - that's what editing and appearance tools do! So...
> that capability (pun intended!) is a requirement at the protocol level,
> although I don't think we've even brushed on how to define it yet. It would
> be intriguing if the protocol were such that the client could expose a
> DOM-like view of the world to local scripts to observe and mutate.
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>