Subject: Re: [ogpx] Limits to interoperability of scripted objects

From: Morgaine <[email-masked]>
Date: Tue, 10 Nov 2009 03:56:01 +0000

On Tue, Oct 27, 2009 at 4:51 PM, Joshua Bell <[email-masked]> 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 <[email-masked]> wrote:

> Good analysis as usual, Morgaine!
>
>
> On Mon, Oct 26, 2009 at 10:15 PM, Morgaine <[email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: Lawson English <[email-masked]>
Date: Mon, 09 Nov 2009 21:32:30 -0700

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 <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>> 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.
>
>
>     * 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.
>
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Joshua Bell <[email-masked]>
Date: Tue, 10 Nov 2009 09:19:33 -0800

> http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion ...
Nifty stuff. What do you think needs to be exposed at a protocol level to
enable these scenarios, and do you think that fits into any of the currently
sketched out drafts or forms a part of an as-yet unidentified draft? It
sounds like much of it is captured by the use case: clients are able to
manipulate simulation state for avatars and other objects.

  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.

No disagreement. It's also interesting to think about stretching the VWRAP
model towards P2P scenarios. The model dictates that there is an
authoritative service for a region, but it's conceivable that if I invite
you to my space, I have a single application on my personal host that is
providing both the agent services and region services, and negotiates with
your personal host's agent service.

> 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)
>

...which points out there are at least two scenarios for client-side dynamic
code: stuff that runs with effectively full trust of the user (basically has
unfettered access to agent and region services on the user's behalf) and
stuff that must be sandboxed. The former category would include the client
application itself as well as "Greasemonkey"-style extensions. The latter
would include content from arbitrary objects, much like JavaScript within a
web page running within the browser security context. Intriguing... it seems
like the Same Origin Policy from the web could apply directly to any set of
VWRAP services as well, although if the logic is coming from user-generated
content rather than the region authority itself, this runs into the same
exciting world that Google and others face with advertisement-hosted scripts
which need to be further sandboxed so that ads can't monkey with your
account, despite being served from the same domain.

---

From: Carlo Wood <[email-masked]>
Date: Tue, 10 Nov 2009 21:11:57 +0100

On Tue, Nov 10, 2009 at 09:19:33AM -0800, Joshua Bell wrote:
> sketched out drafts or forms a part of an as-yet unidentified draft? It sounds
> like much of it is captured by the use case: clients are able to manipulate
> simulation state for avatars and other objects.

I'd also like to ask some attention for synchronization:

Apart from vehicles (which totally don't work for me in SL due to lag)
there are lots of cases where a desync could be avoided by having
the client calculate (locally) what is the position of that what
it's avatar interacts with.

Most common example: hugging another avatar. Right now avatars are
clumpsy bumping into eachother in an attempt to "sync" the distance
and then stick an arm straight to their friends stomach, or attempt
to hug the air completely.

Assuming client-side scripting, I hope there will be SOME way to
make animated hugs (or any couple animations) really work (with
effort). In my mind this would mean that two (or more?) viewers
negotiate what couple (or multi-) animation they want to play
and then ask the server for a mere 'start signal', after which
each client plays all the animations for all the avatars involved
locally, until the server says: ok, animation terminated.

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 10 Nov 2009 21:41:55 +0100

On Tue, Nov 10, 2009 at 09:11:57PM +0100, Carlo Wood wrote:
> effort).

without*

Here is an idea of how it could work:

* Viewer A (or object) initiates Multi-gesture Request
  to N (other) viewers, this involves a list of the
  animations (UUID) to play for each of the avatars
  involved, and sounds to play etc, and the starting
  position in the world of each avatar.
* Each viewer reacts with: Ok, will try; or Nope, I won't.
  If any viewer denies the request (or times out?)
  then the server informs all viewers that the multi-
  animation was aborted (and why). [ An optional flag
  could be to continue anyway, but without the avatar(s)
  that don't want to. ]
* Once all avatars that want to play the multi-animation
  are known, the server sends them a message: "We have a go!"
* All viewers that have all the needed information to
  continue (downloaded and cached the animations, sounds etc)
  send a message to the server: "ready!"
* As soon as all viewers are ready (optionally, a parameter
  of the original request includes a timeout after which
  the delayed avatar is considered to have said "no"),
  the server informs all viewers to start playing the
  multi-gesture.

And YAY! finally a completely synchronized couple (and
multi) animation, even synced with sound!

Options in case of delays (timeouts) should be:
- Play as soon data available locally,
- Wait till at least N, or at least those, avatars
  are ready.
- Abort completely if any can't play in time.
- If someone is delayed and the rest already plays
  the animation, then the viewer can decide to abort
  or play the animations locally anyway, as soon as
  they become avaiable, etc etc... All those possibilities
  are mere bits in already existing messages, so why not.

As a side effect of this it should be possible to
play a gesture involving animation and sound by ONE
avatar (as are the gestures in SL now) but *synchronized*:
everyone sees it at the same time, and the animations ARE
synced with the sound once the start to play (unlike now,
where the animation is played and 30 seconds later you
hear the sound).

---

From: Morgaine <[email-masked]>
Date: Tue, 10 Nov 2009 22:36:45 +0000

+1 Lawson. :-)

I don't want to endorse any single linguistic approach to client-side
scripting, as that would deny the opportunity for progress along many
different language fronts in parallel.  It would also limit the scope for
using the many language-specific development tools available today, and it
would not harness the skills that people have earned with particular
languages and tools.

In my view, the right approach to client-side scripting is to "*provide none
but support all*", through the simple strategy of defining a socket API for
scripts that attach to viewers as regular system processes.  This
automatically provides support for hundreds of languages that have socket
libraries, makes full use of multiple cores with zero effort in
parallelization, and avoids the vast majority of pitfalls associated with
concurrent programming using threads and shared memory.  It delivers a large
number of other benefits as well, too many to describe here.

For more detailed information on this approach, the wiki page at
https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft provides
a wealth of considerations for an entire viewer structured around such a
design.

For client-side scripting within existing SL viewers, the language-agnostic
/ scripts-as-processes idea was captured a year ago in a tentative subsystem
design for the third-party Imprudence viewer (derived from LL's GPL
sources).  The overall architecture is illustrated in this diagram --
http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png .
Further details can be found in the threads marked "Plugins" in the
Imprudence Development forum --
http://imprudenceviewer.org/forums/viewforum.php?f=7  .

So how does all this tie in with VWRAP?  The way I think it should be tied
in is by thinking of the client-side "consumer" of the protocol not as an
application, but as an API that can be used by many different types of
application.

Focusing on a "viewer" in traditional SL terms will tend to drive protocol
design towards a non-automated future with poor computational properties, in
much the way that the focus on human-controlled browsers has led to websites
that need to be scraped for data --- a very inferior way of developing
interfaces to systems.

The SL viewer was designed in "the browser way" (the intended consumer is
expected to be a human with all relevant limbs and senses available), as a
result of which there is no clear inner API to which a client-side scripting
engine can be cleanly interfaced, nor is there a clear means of adapting the
endpoint for accessibility, nor for automation.

We can improve on this by thinking of the client end of the protocol as an
LLSD-based API and ensuring that it is full-featured and well supported by
the protocol, rather than as an application as the OGP documents currently
describe it.  Full applications usually have a rather ill-defined feature
set, whereas APIs can be tightly defined and checked for coverage, which
translates immediately into a more understandable design and far more
testable implementations.

I'd like to see a change of emphasis from "viewer application" to "viewer
API" for the above reasons, as a generalization of the software that hosts
the client-side endpoint.  Even more concretely, we should be thinking in
terms of *libraries* as concrete implementations of VWRAP, in exactly the
same way that libomv did when it reverse-engineered the SL legacy protocol.

A self-contained protocol library would be a far cleaner and more
maintainable factoring of the software, compared to dispersing the protocol
implementation into the mysterious depths of a very large monolithic viewer
that is widely acknowledged to be poorly structured and too monolithic.
Adding even more code to the main body of the application just compounds the
current problem.

Unfortunately, "dispersing the protocol implementation into the mysterious
depths of a very large monolithic viewer" is exactly the route currently
being taken for prototyping the protocol.  I believe that choosing that
approach was a mistake on several grounds, not the least of which is that it
provides a very obscure and inflexible platform for testing and modifying
our protocols as they evolve.  Protocol development and testing requires the
opposite of these properties.

I recommend that that decision be reconsidered before more time and effort
is spent in a direction that has limited utility for protocol development.
A protocol library would be far easier to understand, maintain, and
develop.  It would not bloat the main body of viewer code further, it would
be testable with far greater ease by calling it from scripts, and it would
be open to far more eyeballs than the current viewer which represents a
substantial challenge to practically all its developers.

Morgaine.

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

On Tue, Nov 10, 2009 at 4:32 AM, Lawson English <[email-masked]> wrote:

> 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.
>
> 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 <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>> attributes could specify the language and maybe a startup argument list too.
>>  (These are just random ideas, not cohesive.)
>>
>> 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
>> On Tue, Oct 27, 2009 at 4:51 PM, Joshua Bell <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: Carlo Wood <[email-masked]>
Date: Wed, 11 Nov 2009 11:12:16 +0100

My previous post was a brainstorm, and I made a view mistakes in it.
Let me try again.

Looking just at animations and sounds, we can observe that it
is impossible to deny playing a sound, and it is only possible
to deny playing an animation for ones own avatar. Nevertheless,
more in general one could think of world-manipulations, visible
to others, and requested by others, that require permissions,
the whole set of permissions can than be seen as a bit mask,
but is at the moment of no further interest. Hence, lets
concentrate for the sake of simplicity on animations.

The simplest case would be a scene with three avatars (agents,
whatever) A, B and C, where A proposes to animate B (to B)
and C is just an observer.

In the ideal situation without much lag, the protocol should
look something like this (were B/xyz and C could be a list of
agents/animations):

[A preloads animations (etc)]
A --request animation xyz of B--> simulator
simulator --A requests animation xyz --> B
[B starts preloading animations (etc)]
simulator --A requests animation xyz of B --> C
[C starts preloading animations (etc)]
B --OK--> simulator
simulator --Ready?--> A,B,C
A --Ready--> simulator
B --Ready--> simulator
C --Ready--> simulator
simulator --GO--> A,B,C
[all viewers play the animations for all avatars]

HOWEVER...

It seems better to seperate this "voting / handshaking" from whatever
is the action. If we assume an API, as morgaine proposed, that gives
us complete control over the world, then a logical step would be
to have a viewer-local scripting language that manipulates this
world (albeit locally, in this case). A given script provided by
another agent would fail if it would attempt to do something for
which it had no permission; so it should be known what permissions
a script needs before running it.

The above then can be done by replacing "animation(s)" with "running
a script". In the above case, the script would only need the
permission "animate your avatar for animation xyz".

The above then turns into:

[A preloads animation (etc)]
A         --requests to run script on B,
            needing permission "animate B with xyz"-->  simulator
simulator --A requests to run script,
            needing permissions "animate B with xyz"--> B
[B starts preloading animation (etc)]
simulator --preload animation xyz-->                    C
[C starts preloading animation (etc)]
B         --OK-->                                       simulator
simulator --script-->                                   B
simulator --Ready?-->                                   A,B,C
A         --Ready-->                                    simulator
B         --Ready-->                                    simulator
C         --Ready-->                                    simulator
simulator --GO-->                                       A,B,C
[all viewers run the script]

Now, although EVERYTHING can be implemented from here on with
"running client-side scripts" (possibly predefined, permanently
cached scripts), I'd personally add one more step to seperate
the 'voting' mechanism from 'running a script'.

I think the most general support would be to first define
that some handle means "play script needing those permissions",
and then run the voting protocol, including it's timeout
and permission-denied policies, using that handle; in that
case the voting would look like:

* Define what we vote on, and what are the timeout/permission-denied
  policies, and obtain voting-handle

* Handle preloading (tell everyone that they might need these assets).

* Ask for permissions
* Wait for permissions and/or timeouts

* Inform viewers of result about voting-handle

* Wait for preload-ready signals
* Inform viewers that everyone is ready and we have a 'go'.

* All viewers do as agreed, resulting a mutally synchronized
  experience.