Subject: [vwrap] Relationship between Avatar/Agent and Asset Service?

From: Izzy Alanis <[email-masked]>
Date: Tue, 29 Mar 2011 10:58:30 -0400

Starting new thread as the previous one is becoming too unwieldily.

Morgaine said:
> We either have interoperability between worlds, in which an inhabitant can travel from one world to another and take their avatar and/or possessions with them, or else we don't have that.  It's black and white, and no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it.

The world is full of shades of grey.

Is there an assumption that an Avatar has/uses one (and only one?)
"Asset Service" -- that I have a single repository of possessions to
take? Can I have and use different asset services? Can I use multiple
asset services? Can people share?

 - Izzy

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 16:46:47 +0100

Izzy, several months ago on this list I was discussing exactly that issue
with Joshua, highlighting how multiple asset services being handled
simultaneously by regions and clients is the scalable way of achieving
virtual tourism of visitors from multiple separate worlds to a central
"tourist world".

Those tourists each have asset services back in their home worlds or on 3rd
party asset services, and on arriving in the tourist zone the region needs
to hand out references to assets in all those remote asset services for the
clients to be able to render all the people present with their correct
avatars and possessions.

So the simple answer is "No, no assumption of single asset service."  That
would not be a scalable design anyway.

Morgaine.

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

On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis <[email-masked]> wrote:

> > We either have interoperability between worlds, in which an inhabitant
> can travel from one world to another and take their avatar and/or
> possessions with them, or else we don't have that.  It's black and white,
> and no amount of fudging about "service level interoperability" is going to
> overcome the lack of VW interoperability as a user would understand it.
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 29 Mar 2011 11:54:42 -0400

I mean to question the cardinality of the relationship between
avatar/identity and asset service(s). Does an avatar only have a
single home asset server, or can I simultaneously access assets
provided by 3rd party asset services? Can I access "AssetServicesRUS
(TM)" and services provided by "Acme Asset Services, LLC"? Or is my
identity intractably linked with a particular asset service provider?

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 17:18:43 +0100

Any number of asset services per user.

We generally frown on singletons, but a more important reason for "multiple"
is that a given provider may limit your freedom to hold items in ways that
you do not wish, so it's important that you be able to keep other stuff
disallowed by that provider elsewhere.

There are lots of other reasons for "multiple" too.  For example it is very
likely that people (power users at least) will want to set up an asset
service for backups (either local or in the cloud), which will become ever
more important as VWs contain more and more of our virtual items and backups
become crucial.

I hope that answers your question about cardinality.

Morgaine.

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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 29 Mar 2011 09:38:24 -0700

Hey Izzy,

FWIW... despite what morgaine says, the original members of this group
were actually interested in "service level interop." and here's the
use case.

part of the reason Linden was interested in open protocols was so we
could attempt to become the center of a much larger virtual ecosystem.
the vision we shared with some of our partners was a world where you
could log into Second Life or OpenSIm instance with your facebook or
twitter credentials. or google. or yahoo! or OSGrid or Linden / Second
Life. we also wanted to allow individual organizations (either your
corporate IT department or a commercial online service like the
Wikimedia commons) to act as an asset server for your inventory. we
wanted to give individual grid deployers (or even individual users)
the ability to pick who routed their voice and audio packets.

these are just a few examples of the use cases we wanted to support
that we felt justified "service level interop."

people who wanted to be able to walk from one world to the other,
could still do that, but only if both virtual worlds supported enough
services to move avatars between them.

so "virtual worlds level interop" is less interesting, IMHO, since it
requires participants to effectively implement all services if they
want to participate in the virtual world.

now... Linden, IBM and Intel seem to have de-prioritized their
participation in this group, so it's certainly a valid thing to say
"hey, let's focus on full-on VW interop." but ultimately, this will be
limiting your participation to a much smaller community of deployers.
and at the end of the day, you're going to have to specify services
as... well... services, so the VW interop thing has always seemed like
a red herring at worst and an artificial constraint at best.

the current charter was developed at a time when "service level
interop" was the assumption, which is why we split off each service
into a different document. the charter was also too small a document
to capture the assumptions of the types of systems we wanted to work
with, which is why in 2009 Dave Crocker recommended we put a bare
minimum in the charter with the understanding that the intro doc would
expand that understanding.

so... if peeps here want to continue with service level interop,
that's fine. we _may_ be able to keep the same charter and even some
parts of the intro doc. if we want to go with full-on interop between
OpenSim instances, that will probably necessitate a change in the
charter and definitely a change in the intro.

just my 2 cents.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 29 Mar 2011 09:52:32 -0700

Always remember the use case of one business that has one public VW and 
their private asset server which any number of internal clients can 
connect to and publish assets to the public VW. Once any asset is 
published then any number of external clients could then see the asset, 
work on it, or maybe even get a local asset version of the published asset.

Meadhbh Hamrick wrote:
>>> We either have interoperability between worlds, in which an inhabitant can travel from one world to another and take their avatar and/or possessions with them, or else we don't have that. �It's black and white, and no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it.
>>>       
>> �- Izzy

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 18:14:02 +0100

> want to participate in the virtual world.

No it does not.  Any virtual world is free to implement as few or as many
services itself as it wants, or to choose 3rd party services in their place,
or none at all, or any combination of these strategies.  This is why David
produced his VWRAP Deployments document, to highlight the total flexibility
that would exist.

As to "less interesting" ... well virtually all VW users who reside in more
than one world would disagree that it is "less interesting".  In fact, they
do often state in no uncertain terms how hugely desirable such interop would
be, and how extremely annoying it is to live without it, like RL planets
lacking any means of transport between them.

What's "less interesting" is producing a protocol that produces walled
gardens and provides nill interop between them, because that is what we have
already today.

Morgaine.

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