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

David W Levine wrote:
>
> A lot of words have been spent on this. Let me try to walk through my
> perspective.
>
"Federation of regions" is a poor choice of terms, unless you also call 
the collection of web servers that power Facebook "a federation of web 
servers". That's not how people usually use that word (e.g. 
http://www.ibm.com/developerworks/library/specification/ws-fed/). What 
we have for each virtual world is a collection of simulation servers 
that are all under the same authority -- in all similar to Facebook's 
web servers. In fact, OpenSimulator's simulation servers serve http, so 
the difference between Facebook's infrastructure and an OpenSimulator VW 
with many simulators is only on the applications that they run.

Really, we don't need to reinvent wheel when it comes to large-scale 
decentralized, but interoperating, systems. The Web has been around for 
a while. What we're dealing with here can be modeled as one application 
on top of the Web, even if for the time being we use a phat client 
instead of a web browser, because it renders things faster than WebGL.

>
> 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
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>   