Re: [vwrap] Call for a vote on interop BETWEEN independent virtual worlds or not

[Cristina Videira Lopes <[e-mail]>]

The terminology and the model suggested in the documents, and now once 
again reinforced in the emails, are different from the standard  
terminology and model used for the large-scale decentralized system that 
is already mature and well established, known as "the Web."

The web is a large-scale, client-server architecture, system composed of 
millions of independently-operated web sites, each treated as a black 
box of engineering and policy decisions made by one independent 
authority, running applications whose only contract is to use the HTTP 
protocol for interaction with user-driven clients. The HTTP protocol is 
a [mostly] stateless protocol that uses hypermedia as the engine of 
application state (HATEOAS),  including accepting higher-order functions 
as "media", and that explicitly embraces the existence of caches. 
Besides interacting with user-driven clients, these web applications can 
engage in interactions with each other, and that concept is known as web 
services.

Now...

- We can invent a new kind of large-scale decentralized system for 
virtual worlds that is different from the Web, starting with using 
different, and sometimes conflicting, terminology, and continuing to 
modeling individual services as the granularity of interaction.

Or

- We can model virtual worlds as web applications, sticking to standard 
concepts and terminology such as "web sites", "web applications" and 
"web services".

I'm in Academia, so I say: don't let the fact that virtual worlds, and 
all the interop scenarios described here, can be modeled and implemented 
as web applications running on web sites, and using web services, get in 
the way of your wanting to invent something new!

But ultimately, this is a matter of preference. In one case, one can 
make everything from the ground up, and that's fun. In the other, we can 
take advantage of an infrastructure that already exists, and of years of 
accumulated experience and standards. And, eventually, give something 
back to the Web: a simple, secure, configurable mechanism for single 
sign ons and inter-site agent transfers.

This group's choice!

Morgaine wrote:
> Great post, David!
>
> Your formulation makes it easy to show why our earlier problem was 
> indeed a problem.
>
> You start off with the premise that we're doing interop regardless of 
> the level of granularity (reasonable), and then you postulate that by 
> examining sharing of elements across boundaries from small to large we 
> can cover all the bases of interop (reasonable).  Yes indeed, but the 
> trouble we encountered yesterday was that that process from small to 
> large had been halted at the level of granularity of the virtual world.
>
> It was suggested (merely through unfortunate choice of words as we now 
> know) that at this largest level of granularity, there would be no 
> interoperation BETWEEN those granules, that this was not our goal.  
> Using your form of words, there would be no sharing across the VW 
> boundaries at this level, so your reasonable process from small to 
> large was being aborted prematurely.  And that's why it was a 
> show-stopper, since no inter-world tourism would have been possible at 
> the largest scale.  Fortunately this was just a misunderstanding.
>
> The reason why it was a show-stopper can be described also in terms of 
> *services*, in direct answer to your question about what changes would 
> be required in protocols as regions federate into aggregates.  One big 
> change occurs at the discontinuity caused by singletons.  Irrespective 
> of size, a virtual world today is most commonly a walled garden that 
> runs a single asset service for all its regions, a singleton in the 
> asset-handling protocol.  The change from a singleton to > 1 is not 
> evolutionary, so a walled garden would have blocked VW interop 
> technically as well as by policy.
>
> Tourism typically requires regions to handle N+V asset services 
> simultaneously, where N is the number of asset services Native to the 
> region (often just 1) and V is the number of distinct asset services 
> introduced to the region by Visitors concurrently.  It requires these 
> N+V references in order to avoid having to copy assets to the native 
> asset services(s) as visitors arrive, because this would be highly 
> non-scalable if performed by all M worlds in a fully interconnected 
> Mesh of tourist activity.  (N+V is actually just one of many possible 
> arrangements, but they share the common design concept that asset 
> service referencing is required to avoid non-scalable copying and to 
> distribute asset path load across the breadth of the Internet.)
>
> I like your formulation, and I expect that we can indeed devise a 
> size-independent protocol that works for all aggregate sizes, as long 
> as the full gamut of aggregates is treated uniformly.  I am however 
> worried that your scheme seems (at first glance) to rely on the 
> dreaded proxying of everything by the current region on behalf of its 
> host world.  I'm sure that we'll be discussing this issue a lot more 
> in the future. :-)
>
>
> Morgaine.
>
>
>
>
> =====================================
>
> On Tue, Sep 21, 2010 at 1:27 AM, David W Levine <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     A lot of words have been spent on this. Let me try to walk through my
>     perspective.
>
>     One.. yes, of course we're about enabling interop. Whether it's
>     interop
>     between "worlds" "regions" "Services" or "forests" I don't think
>     changes the specification one whit. What we're about is describing the
>     set of services and interactions which enable the deployment of a
>     large
>     collection of systems built in a large number of ways.
>
>     The core goal is to allow users to share virtual regions, assets
>     and services
>     across a broad set of boundaries. So, just for one, starting small and
>     working up.
>
>     The smallest scenario is a single "stand alone" region, which
>     wishes to
>     access resources which it doesn't host. To whit, asset, inventory and
>     agent services allowing the stand alone region to access items and
>     services hosted by others. This, in and of itself is of course
>     interop.
>     The stand alone region wants to fetch items and rez them. A user may
>     wish to log onto the region with an avatar an inventory hosted from
>     other services. The moment we have a region accessing other services
>     interopation is occurring. Its not very interesting interoperation
>     perhaps but useful things happen.
>
>     Now, whether one calls this region a "world" a "region" a "virtual
>     space: doesn't much matter. Its a virtual space which wants to access
>     services from other service providers.
>
>     Multiple virtual regions can be federated to form bigger spaces. The
>     cogent questions are:
>
>     1) What actual services are needed to support a set of regions
>
>     2) Are any changes required in the underlying protocols used by
>     regains to access services because they are assembled into
>     federations.
>
>     3) What are the user's expectations when moving between regains
>     hosted by separate service providers
>
>     Thus far, I've seen several publically exposed service which relate to
>     federated regions,
>
>     1) the "map" Service. I could also see a possible service which helps
>     regions manage placement and adjacency. (But I'm not sure this isn't
>     a per deployment choice, as it may not expose any interface needed
>     for Interoperability. This may also include "membership" in a basic
>     way.
>
>     2) "Federated Seed Cap" which would get you a set of singletons for
>     the federated regions. This might include search, currency, a
>     default authentication/agent service if the federated regions
>     chose to expose it. In short, it makes perfect sense for a set of
>     regions to expose the services they share. (Mind you they can also
>     do it on a per region basis, but this seems sane to do this way)
>
>     I would be delighted to see additional items on this list. The more
>     things which distinguishes a federated collection of sims, the more
>     clarity is likely to be shed on what we mean when a collection of
>     regions is federated.
>
>
>     The second question is "Are there any protocol changes" which are
>     needed when regions are federated? I ask this in all seriousness.
>     Does a region's service interface change because it is part of a
>     federation. If there are specific changes which happen because
>     regions are federated, then clearly we need to account for this.
>
>     The third question is less about how we build protocols then about
>     how we describe how the bits of the system fit together and how users
>     experience the systems we build and deploy.
>
>     The answer, in short is that users expect to teleport and have magic
>     happen. They expect that whatever appearance they have at the
>     start of a
>     teleport will be the same at the end of the teleport. They expect that
>     they will be able to see everyone and everything in the new
>     region, and
>     they expect that everyone will be able to seem them.
>
>     What has to happen for these desires to be fulfilled? The
>     necessary parts
>     of the items the avatar is wearing at the time of the teleport need to
>     be available to both the region, and the clients need to able to
>     access
>     these items and the inbound avatar's client needs access to all the
>     items in the region, and all the items worn by the avatars in the
>     region. (For the purposes of this discussion, assume that data is
>     passed either in line, or by reference to a remotely hosted service
>     returning the data)
>
>     Will this always be true? Probably not. Does the fact that a region is
>     part of a federation impact this fact? I'm having a hard time
>     seeing why
>     it would. The transaction is between the region and the services
>     hosting
>     the related data. When an avatar wants to teleport into a region, the
>     data about it is provided whether rhe region is a singleton or part of
>     a federation. Again, I'm looking for a "how does this change things"
>     point of distinction. None of this says "Federated collection of
>     regions" isn't a useful construct, quite the contrary. Its how we
>     build
>     out collections of regions for lots of reasons, its just important to
>     look at where the concept manifests in terms of things we can
>     define as
>     actual services with interfaces.
>
>     - David
>     ~ Zha
>
>
>
>
>
>
>
>
>
> On Tue, Sep 21, 2010 at 1:27 AM, David W Levine <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     A lot of words have been spent on this. Let me try to walk through my
>     perspective.
>
>     One.. yes, of course we're about enabling interop. Whether it's
>     interop
>     between "worlds" "regions" "Services" or "forests" I don't think
>     changes the specification one whit. What we're about is describing the
>     set of services and interactions which enable the deployment of a
>     large
>     collection of systems built in a large number of ways.
>
>     The core goal is to allow users to share virtual regions, assets
>     and services
>     across a broad set of boundaries. So, just for one, starting small and
>     working up.
>
>     The smallest scenario is a single "stand alone" region, which
>     wishes to
>     access resources which it doesn't host. To whit, asset, inventory and
>     agent services allowing the stand alone region to access items and
>     services hosted by others. This, in and of itself is of course
>     interop.
>     The stand alone region wants to fetch items and rez them. A user may
>     wish to log onto the region with an avatar an inventory hosted from
>     other services. The moment we have a region accessing other services
>     interopation is occurring. Its not very interesting interoperation
>     perhaps but useful things happen.
>
>     Now, whether one calls this region a "world" a "region" a "virtual
>     space: doesn't much matter. Its a virtual space which wants to access
>     services from other service providers.
>
>     Multiple virtual regions can be federated to form bigger spaces. The
>     cogent questions are:
>
>     1) What actual services are needed to support a set of regions
>
>     2) Are any changes required in the underlying protocols used by
>     regains to access services because they are assembled into
>     federations.
>
>     3) What are the user's expectations when moving between regains
>     hosted by separate service providers
>
>     Thus far, I've seen several publically exposed service which relate to
>     federated regions,
>
>     1) the "map" Service. I could also see a possible service which helps
>     regions manage placement and adjacency. (But I'm not sure this isn't
>     a per deployment choice, as it may not expose any interface needed
>     for Interoperability. This may also include "membership" in a basic
>     way.
>
>     2) "Federated Seed Cap" which would get you a set of singletons for
>     the federated regions. This might include search, currency, a
>     default authentication/agent service if the federated regions
>     chose to expose it. In short, it makes perfect sense for a set of
>     regions to expose the services they share. (Mind you they can also
>     do it on a per region basis, but this seems sane to do this way)
>
>     I would be delighted to see additional items on this list. The more
>     things which distinguishes a federated collection of sims, the more
>     clarity is likely to be shed on what we mean when a collection of
>     regions is federated.
>
>
>     The second question is "Are there any protocol changes" which are
>     needed when regions are federated? I ask this in all seriousness.
>     Does a region's service interface change because it is part of a
>     federation. If there are specific changes which happen because
>     regions are federated, then clearly we need to account for this.
>
>     The third question is less about how we build protocols then about
>     how we describe how the bits of the system fit together and how users
>     experience the systems we build and deploy.
>
>     The answer, in short is that users expect to teleport and have magic
>     happen. They expect that whatever appearance they have at the
>     start of a
>     teleport will be the same at the end of the teleport. They expect that
>     they will be able to see everyone and everything in the new
>     region, and
>     they expect that everyone will be able to seem them.
>
>     What has to happen for these desires to be fulfilled? The
>     necessary parts
>     of the items the avatar is wearing at the time of the teleport need to
>     be available to both the region, and the clients need to able to
>     access
>     these items and the inbound avatar's client needs access to all the
>     items in the region, and all the items worn by the avatars in the
>     region. (For the purposes of this discussion, assume that data is
>     passed either in line, or by reference to a remotely hosted service
>     returning the data)
>
>     Will this always be true? Probably not. Does the fact that a region is
>     part of a federation impact this fact? I'm having a hard time
>     seeing why
>     it would. The transaction is between the region and the services
>     hosting
>     the related data. When an avatar wants to teleport into a region, the
>     data about it is provided whether rhe region is a singleton or part of
>     a federation. Again, I'm looking for a "how does this change things"
>     point of distinction. None of this says "Federated collection of
>     regions" isn't a useful construct, quite the contrary. Its how we
>     build
>     out collections of regions for lots of reasons, its just important to
>     look at where the concept manifests in terms of things we can
>     define as
>     actual services with interfaces.
>
>     - David
>     ~ Zha
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>