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

[Morgaine <[e-mail]>]

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