Subject: Re: [vwrap] Networked Communication of Objects: some thoughts

From: Morgaine <[email-masked]>
Date: Mon, 7 Mar 2011 09:16:08 +0000

Christopher, your post
http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a few
weeks ago and its linked PDF gave me much food for thought.  Web-oriented
communication with objects in virtual worlds is useful, but it seems to me
that this is really just a subset of a larger field of interest:
communication *between objects* in virtual worlds.

It's rather remarkable that throughout the long AWG->OGP->MMOX->OGPX->VWRAP
process, we never considered inter-object communication between VWs.  Yet,
communication with and between VW objects is undoubtedly an important aspect
of VW interop, as it provides essential mechanisms for integration.

That was a failure on our part, probably caused by excessive familiarity
with the largest commercial VW service, which unfortunately doesn't
recognize the existence of other virtual worlds and the need to communicate
with them.  We need to do better than this if we're trying to bring in a
future of interop.

Since we're already defining an abstract data type and some serialization
formats to carry it, why don't we extend the role of these definitions to
inter-object communication as well?  It's a relatively small step from LLSD
to an LLSD-based messaging format --- the only additional requirement is a
scheme for VW object addressing so that an LLSD-formatted message can reach
the right object in the intended virtual world.

I can think of several ways of achieving this in a flexible way, and
numerous applications for it.  Perhaps it's worth discussing?

Morgaine.

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

On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird <[email-masked]>wrote:

> Before we turn off the lights...
>
> I have recently written a paper Entitled Networked Communication of Second
> Life® Objects using LSL, php, and MySQL. And it can be found at
> http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects.pdfIts short so I will wait while you read it.
>
> So this got me to thinking, though my application is specific to Second
> Life, there is no reason that communication between objects in various grids
> with non-persistent URLs could not be obtained with a simple extension to
> this method.  Though my method specifically uses the LSL HTTP server (which
> I believe up to this point is not reproduced in the OpenSimulator LSL clone)
> any object in any virtual space that can send and receive HTTP requests
> should be able to join in one of the networks described in the paper.
>
> The best part is that this is built on existing standards and all that is
> needed  in any virtual world to implement something like this is an HTTP
> channel to your virtual object.
>
> Thoughts? Criticisms? Comments?
>
> -- Christopher (ZenMondo)
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

---

From: Lawson English <[email-masked]>
Date: Mon, 07 Mar 2011 11:13:31 -0700

For me, the best existing examples of networked objects are the 
Cobalt/Croquet implementations of David Reed's Teatime Architecture and 
the original Kansas collaborative environment from Sun. Of course, they 
were relatively easy to
implement because the languages used, Smalltalk and Self, are OOP "all 
the way down," so there's no programmer skill required for sending 
messages to remote objects in different applications/computers because 
its all OOP messaging. You can fake the messaging in various ways with 
non-pure-OOP languages, and obviously when more than one language comes 
into play, things get more complicated.

But, the basic relationships stay the same, even with multiple 
languages. Until you examine what is done with the pure OOP 
implementations of this idea, you're going to be limited in what you 
think can be done in this scenario (hint, its a lot more than you 
think... a LOT more) because you'll limit your ideas due to 
complications of the implementation.

My own take is that virtual worlds should take an existing OOP 
implementation, like Teatime, and use it as the lingua franca for 
messaging between worlds. To the messaging system, its all TObjects 
passing messages back and forth. Within the TObject, the implementation 
can be done in any language on any hardware. The hard part, fully 
orthogonal message-passing between remote objects using existing network 
and IPC protocols, has already been solved by TeaTime, so why try to 
reinvent the wheel? Just use Squeak as the carrier for OOP interop 
between worlds and worry about the API between objects in terms of 
smalltalk message definitions.

All else is implementation detail for the behavior of objects within the 
individual worlds, which is an already-solved problem.

Boom. You're done.

Lawson

On 3/7/11 2:16 AM, Morgaine wrote:
> Christopher, your post 
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a 
> few weeks ago and its linked PDF gave me much food for thought.  
> Web-oriented communication with objects in virtual worlds is useful, 
> but it seems to me that this is really just a subset of a larger field 
> of interest:  communication /*between objects*/ in virtual worlds.
>
> It's rather remarkable that throughout the long 
> AWG->OGP->MMOX->OGPX->VWRAP process, we never considered inter-object 
> communication between VWs.  Yet, communication with and between VW 
> objects is undoubtedly an important aspect of VW interop, as it 
> provides essential mechanisms for integration.
>
> That was a failure on our part, probably caused by excessive 
> familiarity with the largest commercial VW service, which 
> unfortunately doesn't recognize the existence of other virtual worlds 
> and the need to communicate with them.  We need to do better than this 
> if we're trying to bring in a future of interop.
>
> Since we're already defining an abstract data type and some 
> serialization formats to carry it, why don't we extend the role of 
> these definitions to inter-object communication as well?  It's a 
> relatively small step from LLSD to an LLSD-based messaging format --- 
> the only additional requirement is a scheme for VW object addressing 
> so that an LLSD-formatted message can reach the right object in the 
> intended virtual world.
>
> On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I have recently written a paper Entitled Networked Communication
>     of Second Life® Objects using LSL, php, and MySQL. And it can be
>     found at
>     http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects.pdf
>     Its short so I will wait while you read it.
>
>     So this got me to thinking, though my application is specific to
>     Second Life, there is no reason that communication between objects
>     in various grids with non-persistent URLs could not be obtained
>     with a simple extension to this method.  Though my method
>     specifically uses the LSL HTTP server (which I believe up to this
>     point is not reproduced in the OpenSimulator LSL clone) any object
>     in any virtual space that can send and receive HTTP requests
>     The best part is that this is built on existing standards and all
>     that is needed  in any virtual world to implement something like
>     this is an HTTP channel to your virtual object.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Tue, 8 Mar 2011 12:11:14 +0000

Interesting points, Lawson.

As you know, IETF protocols are generally concerned with on-the-wire message
exchange, and hence they usually focus on message representation and message
sequencing, as opposed to language-dependent issues such as object
orientation or the syntax of messaging calls.  This has the colossal benefit
of making protocols usable from literally thousands of network-aware
languages.

In this group we are very strongly concerned with interoperability.
Language agnosticism of protocols provides an immense boost for interop ---
the Web would be a much poorer place if its protocols had been defined in
terms of its designers' favorite languages instead of using
language-agnostic messaging.  This is a benefit which we must not sacrifice
away.

Fortunately, your OO-focused suggestion can be incorporated quite easily
into a language-agnostic messaging protocol, because support for OO in a
network protocol requires nothing more than including sender and recipient
fields in each message to identify the source and target objects.  That's
easy.  UUIDs are perfectly adequate as object identifiers even on a
world-size scale.

If we take an on-the-wire ADT serialization of the LLSD kind, and we define
messages which include UUID fields as source/destination object identifiers,
this gives us a sufficient framework for expressing inter-object
communication not only between objects in different virtual worlds, but also
in a manner entirely independent of the languages in which those objects are
programmed.  It's even independent of computing paradigm.

On-the-wire message definitions are truly a lingua franca.  That's where we
need to go.

Morgaine.

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

On Mon, Mar 7, 2011 at 6:13 PM, Lawson English <[email-masked]> wrote:

> Cobalt/Croquet implementations of David Reed's Teatime Architecture and the
> original Kansas collaborative environment from Sun. Of course, they were
> relatively easy to
> implement because the languages used, Smalltalk and Self, are OOP "all the
> way down," so there's no programmer skill required for sending messages to
> remote objects in different applications/computers because its all OOP
> messaging. You can fake the messaging in various ways with non-pure-OOP
> languages, and obviously when more than one language comes into play, things
> get more complicated.
>
> But, the basic relationships stay the same, even with multiple languages.
> Until you examine what is done with the pure OOP implementations of this
> idea, you're going to be limited in what you think can be done in this
> scenario (hint, its a lot more than you think... a LOT more) because you'll
> limit your ideas due to complications of the implementation.
>
> implementation, like Teatime, and use it as the lingua franca for messaging
> between worlds. To the messaging system, its all TObjects passing messages
> back and forth. Within the TObject, the implementation can be done in any
> language on any hardware. The hard part, fully orthogonal message-passing
> between remote objects using existing network and IPC protocols, has already
> been solved by TeaTime, so why try to reinvent the wheel? Just use Squeak as
> the carrier for OOP interop between worlds and worry about the API between
> objects in terms of smalltalk message definitions.
>
> vwrap mailing [email-masked]://www.ietf.org/mailman/listinfo/vwrap
>
>
>