Re: [ogpx] where does VWRAP fit?

[Morgaine <[e-mail]>]

Kari's question is a good one, because it highlights the curious gulf that
exists between the user's perspective of *virtual worlds* and the
implementation perspective embodied in the OGP documents.  Much has been
made of the alleged ambiguity and uncertainty about this term, but this is
really not true at all.

*Users* of *virtual worlds* know exactly what the term means, in the same
way that they can distinguish one country from another when they go on
holiday.  People have been living with the concept of different places ever
since they started travelling beyond their village boundary, and nowadays
the popularity of tourism embodies that concept most vividly in the form of
*countries*.  Different countries tend to look different and have different
cultures and different rules (local policies).  This is entirely natural and
instinctive to us.

That concept doesn't disappear when "places" become digital.  Instead the
concept blossoms, because without the constraints of the physical world,
virtual places can be so dramatically different.  The huge diversity means
that "virtual worlds" cannot be defined prescriptively, but there is no
ambiguity at all about the separation and independence of virtual worlds as
a concept.  That concept is hardwired within us from physical experience.
As our imaginations are freed by the technology, the diversity and
independence of virtual worlds can bloom while still enjoying a common
protocol for communication.

The only thing that has ever created any confusion about "virtual world" in
the context of  OGPX is the invention of a completely new and totally
unnecessary semantic for the phrase within the protocol documents, a
semantic that bears no relation whatsoever to normal usage.  I'm glad that
we managed to remove the source of the confusion from the charter, but now
comes the larger task of removing it from the protocol documents as well.

Having removed it, we can then address how VWRAP implements the
user-oriented requirement of interop between multiple virtual worlds, since
removing the "single VW" will allow us to refer to more than one VW.  We've
already been told authoritatively that, as it stands, the protocol will only
connect single regions or a region domain of regions to one single virtual
world, and not interop with a whole other VW.  However, that goal has been
extended recently in informal discussions, with a hint that more than one
Agent Domain could be made to interact.  That would indeed be the start of
interop between multiple VWs, as users know them.

I look forward to that.


Morgaine.







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

On Sun, Sep 6, 2009 at 5:04 PM, Kari Lippert <[e-mail]> wrote:

> I present this perspective and ask this question to try to clarify
> these concepts within my mind. All I ask is that you run with me on
> this and think, not react. I am hopeful that this question and these
> simple assumptions might inspire the great thinkers on this list to
> forge ahead.
>
> As I understand it, a "virtual place" is somewhere my "virtual
> representation" can go.  The "public" calls these the "virtual world"
> and an "avatar" for convenience. What the "public" is not necessarily
> aware of (nor do they want to be), is what goes on behind the curtain
> so to speak. The "virtual place" doesn't exist anywhere, so you can't
> actually have connectivity between two of them. You can, however, have
> the illusion that two "virtual places" are connected. (Abandon here
> all philosophical thoughts ye strain to have about this illusion or
> the perception thereof - it matters not for the moment.) In the really
> crude sketch that I've attached, this is represented by everything
> above the red line.
>
> My view of what really does exist is a set of "services" that create
> this "virtual place": a service that handles authentication and trust;
> a service that provides logging; a service that provides world
> construct management; a service that provides avatar management; a
> service that provides visual representation; a service that provides
> event management; a service that provides messaging; a service that
> provides physical infrastructure; and so on. How a company uses this
> set of "services" to create their "virtual world" may vary but it is
> my guess that there is a lot of commonality. [As an aside, it is not
> necessary that these "services" be implemented in any particular
> fashion, such as SOA, so please don't get hung up on that detail.]  In
> the sketch, this is shown as a set of colored boxes within a gray
> shape. To me, the gray shape is an administrative domain (I
> acknowledge that it might actually be only a part of a company even
> thought the drawing does not show that. Stay with me here - don't get
> lost down a rabbit hole!)
>
> The conceptual commonalities amongst these sets of "services" can be
> represented generically. Representing these  commonalities
> generically, IMHO, is important for the purpose of developing this
> protocol. One can then use a set of generic representations to
> describe a "collection of services that create the perception of a
> virtual place" which is what those below the red line mean when they
> speak of a "virtual world."
>
> My question is where VWRAP fits in this view. The "public" desire is
> to have "interoperability between virtual worlds" so clearly to them
> it is the double line between the two "virtual worlds." Behind the
> curtain, what does that become? Does VWRAP interconnect these various
> "services"? All of them one to another, or just some of them? Given
> what I understand you wish this protocol to be, I believe VWRAP is
> destined for existence at this "service" level - each of these
> "services" becomes a VWRAP endpoint.
>
> Ultimately, given the various payloads envisioned for transport using
> this protocol (as described generally in the proposed charter), I
> believe VWRAP is actually a set of related "service" specific messages
> that can be used to give the user a perception of connectivity.
> "Services" will then be able to communicate freely without constraints
> of "meat world" authority or responsibility.
>
> It doesn't make sense to me to relate what the protocol could be
> applied to to what I understand as the notion of "region domain". The
> last email interchange hinted at the issue with that. Each of these
> "services" could be implemented by a different administrative
> authority (the perfect world of the service oriented architecture)
> thereby being shared across what I think you are calling "region
> domains". I think a more flexible boundary distinction might be to
> define a "trust region" - a set of these "services" that can be
> accessed without a different authentication [note that I do not mean a
> re-authentication to make sure it is still you but rather permission
> to cross a trust boundary]. The trust boundaries can be related to one
> "meat world" administrative authority or can span several depending on
> the trust model they share.
>
> It is my hope that this crude sketch will support your understanding
> of my perspective. While I recognize that this view might be a bit
> strange (it did come from my mind after all), if it is wrong I would
> appreciate your corrective comments, but let's not get hung up on
> perfecting this sketch. It is only given to help you consider the
> question I ask: Given this view of "services" that create the illusion
> of a "virtual place," where (or how) does VWRAP fit? Is it, as I
> believe it to be, between the orange "service" and the yellow
> "service" so that they may understand and exchange with each other the
> aspects of the illusion for which they are responsible?
>
> I hope this helps - I don't want to blow things up again but I do need
> this clarity.
>
> Kari
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>