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

[David W Levine <[e-mail]>]

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