Morgaine has seen me hype this many types, but perhaps Joshua and others have not not:
http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion ...
There's many uses for client-side scripting, from custom GUIs to manipulation of elements (avatars, objects, etc) going out to the sim directly, to manipulating objects client-side only say for use in a mechanima play where only the other characters in the play can see what is going on. Hybrid situations, as is done with the puppeteering code mentioned at the bottom of the page, could delay updating until everything is resolved client-side. A collection of avatars could be participating in a private play, battle, simulation, whatever, and only use the main simulator to provide a backdrop for whatever it is they are doing with or without eventually updating the simulator as to their position/actions/etc.
And no doubt there are many other scenarios that we haven't conceived of yet where "client side scripting" would be useful. And one extreme is the Second Life use-case where the server handles virtually every aspect of the avatar except limited user input. At the other end is the Croquet/Cobalt case where clients act as servers for their own private worlds that are, in principle, P2P in nature. While the VWRAP scenario assumes more Second Life-ish scenarios, there's plenty of room for more Croquet-like situations, IMHO. The server(s) need not know what input the client is working with. Perhaps there's enhanced physics being used in a special MC Escher style world. or perhaps the client is getting a direct feed of planetarium data to light up the sky. Both situations exist or are being worked on in a rudimentary way in Second Life itself. There's no reason to assume ANY limitations save those required for security/trust issues, and those will need to be applied on the server side for any realistically secure scenario (assuming that the client-side plug-ins are trustworthy for the end-user's purposes, of course)
Lawson
Morgaine wrote:
On Tue, Oct 27, 2009 at 4:51 PM, Joshua Bell <josh at lindenlab.com <mailto:josh at lindenlab.com>> 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 <josh at lindenlab.com <mailto:josh at lindenlab.com>> wrote:
Good analysis as usual, Morgaine!
On Mon, Oct 26, 2009 at 10:15 PM, Morgaine
<morgaine.dinova at googlemail.com<mailto:morgaine.dinova at googlemail.com>> wrote:1. Make script state transfer a deployment option: both
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):
2. Worlds running different scripting engine
source and destination regions have to allow script
state transfer for it to happen.3. Define a common scripting language and virtual machine
implementations do not transfer state and hence scripts
are initialized on teleport.4. If script state continuity is desired on teleports
environment --- ie. a web-like _javascript_ approach but
for regions.ogpx at ietf.org <mailto:ogpx at ietf.org> ------------------------------------------------------------------------
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
_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.