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

[Meadhbh Hamrick <[e-mail]>]

kk. i think i understand your heartburn.

i think everyone's objective here was to have services that would
implement a "base level" virtual world. but that being said... there
are lots of reasons why different kinds of services in OpenSim or
Second Life might not want to be part of a spec. the linden dollar
interface, for instance, is bound to be contentious and the only
reason to specify it would be if linden wanted to open the interface
to other grids (which, i'm pretty sure they're not interested in doing
at the moment.) not to mention the outcry by peeps who are using other
game cash systems.

also, i've been wondering about the map service (talking about the
thing that draws the human readable map, not what i've been calling a
"space" server that stores the adjacency graph for region boundaries.)
do we really need a special protocol to access map tiles? maybe it's
enough for a region or collection of regions or whatever to publish a
URL to a HTML/JavaScript based map.

just thinking out loud here.

moral of the story is, _I_ think we got consensus that there were
going to be some features that are in Second Life today that won't
show up in VWRAP. However, we will define enough services to have
something recognizable as a virtual experience.

i predict there will be some disagreement about which services should
be supported by the protocol and which should be left as private
extensions. but i do, however, think it's a good idea to enumerate
them somewhere. we started to do that in the charter, and there are
some services enumerated in the intro draft, but i think we should all
go through the list of services and see what we think should be in /
what should be out.

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



On Mon, Sep 20, 2010 at 5:52 PM, Morgaine
<[e-mail]> wrote:
> Cool, Meadhbh!
>
> The services themselves have never been a worry to me.  The great thing
> about services is that they're decoupled and potentially external, so any
> mistakes or inefficiencies can be corrected quite easily, and they can be
> scaled up using standard techniques.
>
> What was worrying me instead was that, although services can be defined to
> do anything, the core protocol may not provide enough glue to bring services
> together to implement the more complex deployments required by interop
> between worlds.  Solutions for tourism do not pop out of the wash without
> careful design.  You cannot design a core protocol sufficient for
> implementing walled gardens and automatically expect it to be sufficient to
> enable more complex interop scenarios.  It may be sufficient, and it may
> not.  You have to plan for it, by careful choice of protocol and services,
> if you want to be sure that the complex interop cases are met.
>
> And this is why I need us to be able to examine complex use cases such as
> tourism from the perspective of user-level elements such as worlds and
> possessions and operations between worlds.  It is to allow is to devise a
> sufficient set of services and protocol glue to allow those use cases to be
> met.  Services are great, but for users they're just a means to an end, and
> I want to be sure that the end is achievable with them.
>
> I hope that this outlines my approach to the problem ahead adequately.
>
>
> Morgaine.
>
>
>
>
>
> ===============================
>
> On Tue, Sep 21, 2010 at 12:17 AM, Meadhbh Hamrick <[e-mail]>
> wrote:
>>
>> okay... and this time copying to the list like i was trying to before
>> (morgaine, you'll get two copies of this.)
>>
>> morgaine. thanks for validating my "single service deployment model."
>> that was the core of what i was after.
>>
>> also, i _think_ i understand your concern with a "service level"
>> definition. i _think_ you're concerned that it is easy to define
>> services in such a way that they might have no practical effect on the
>> user experience of the "virtual world." or that they might detract us
>> from describing protocol flows in such a way that information in the
>> flows needs to eventually affect the scene being rendered on a client.
>> or something like that.
>>
>> if i read your comments correctly, you would like to see more verbiage
>> in the intro doc that correlates architecture and objectives with user
>> experiences. and that's something i can totally respect.
>>
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>
>>
>>
>> On Mon, Sep 20, 2010 at 4:15 PM, Meadhbh Hamrick <[e-mail]>
>> wrote:
>> > morgaine. thanks for validating my "single service deployment model."
>> > that was the core of what i was after.
>> >
>> > also, i _think_ i understand your concern with a "service level"
>> > definition. i _think_ you're concerned that it is easy to define
>> > services in such a way that they might have no practical effect on the
>> > user experience of the "virtual world." or that they might detract us
>> > from describing protocol flows in such a way that information in the
>> > flows needs to eventually affect the scene being rendered on a client.
>> > or something like that.
>> >
>> > if i read your comments correctly, you would like to see more verbiage
>> > in the intro doc that correlates architecture and objectives with user
>> > experiences. and that's something i can totally respect.
>> >
>> > but for what it's worth, i disagree with your characterization of a
>> > federated collection of services as "a walled garden." certainly if
>> > you are not a student enrolled in a class and you can't get into a
>> > region operated by a university, the difference between "federated
>> > collection" and "walled garden" is moot.
>> >
>> > but ultimately, collections of regions that share a federation of
>> > services can decide for themselves which servers they choose to
>> > connect to and which users they allow to access their region. i think
>> > it's unfair to characterize such a deployment model as a "walled
>> > garden."
>> >
>> > -cheers
>> > -meadhbh
>> > --
>> > meadhbh hamrick * it's pronounced "maeve"
>> > @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>> >
>> >
>> >
>> > On Mon, Sep 20, 2010 at 3:48 PM, Morgaine
>> > <[e-mail]> wrote:
>> >> On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[e-mail]>
>> >> wrote:
>> >>
>> >> some of us on this list are interested in deploying only a subset of
>> >> services, so it is FAR from being settled. when you say "we already
>> >> agree" i feel you're dismissing my concerns.
>> >>
>> >>
>> >> I had hoped that this wasn't going to be reopened, but I think we're
>> >> still
>> >> OK.  Your concerns ARE being met.  Your preferred deployments are every
>> >> bit
>> >> as important and as relevant and as supported as those of people who
>> >> wish
>> >> their VWs to interoperate.  Single services are a perfectly valid
>> >> deployment, one possible subset of the overall picture of multiple
>> >> interoperating worlds.
>> >>
>> >> Joshua indicated that he believed that we are settled on a common goal
>> >> but
>> >> are using different terminologies, and Barry indicated that he hoped
>> >> that we
>> >> were arriving at a common goal too.  I believed that to be the case as
>> >> well.
>> >>
>> >> And the evidence on the list indicates very clearly that we are working
>> >> towards common goals.
>> >>
>> >> Since we have been talking about interop BETWEEN virtual worlds in
>> >> hundreds
>> >> of emails, it is clear that this is what we are engaged in, even when
>> >> using
>> >> the terminology of services.  This does not mean that all VWRAP
>> >> deployments
>> >> will involve interop between VWs of course.  Any world that does not
>> >> wish to
>> >> interoperate with others can simply refuse connections and hence
>> >> operate as
>> >> a walled garden.  This is built into David's concept of deployment
>> >> options,
>> >> and it's so easy! :-)
>> >>
>> >> Non-communicating walled gardens are supported just as much as
>> >> interoperating worlds.
>> >>
>> >> With regard to examples showing how services map to user concepts, yes
>> >> indeed, we will need to do that!  And now that VWs may interoperate, we
>> >> can.
>> >> :-)
>> >>
>> >>
>> >> Morgaine.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ===================================
>> >>
>> >> On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[e-mail]>
>> >> wrote:
>> >>>
>> >>> morgaine.
>> >>>
>> >>> some of us on this list are interested in deploying only a subset of
>> >>> services, so it is FAR from being settled. when you say "we already
>> >>> agree" i feel you're dismissing my concerns.
>> >>>
>> >>> i respectfully disagree that we cannot construct use cases useful to
>> >>> virtual world deployers without high level abstractions like virtual
>> >>> worlds, teleports, avatars and clothing.
>> >>>
>> >>> but i do agree that if you are wanting to define interop BETWEEN
>> >>> virtual worlds, then yes, you do.
>> >>>
>> >>> what about the idea of creating a hypothetical example of a virtual
>> >>> world that includes these high level abstractions (users, avatars,
>> >>> teleports, clothing, etc.) but then goes on to define them in terms of
>> >>> services that do not need these high level abstractions to work.
>> >>>
>> >>> so for example, we could have the "high level" virtual world
>> >>> abstraction define data formats for prims, collections of prims,
>> >>> references to textures, sounds, animations, etc. but at the service
>> >>> level we simply call them "assets." that way i could put an asset
>> >>> meta-data server in front of the wikimedia common's web server and
>> >>> have it serve "assets" in a way that is independent of a virtual
>> >>> world. if asset access is independent of a virtual world, you could
>> >>> actually have an asset served directly from the asset service to an
>> >>> offline editing tool or a web page that simply used WebGL to render
>> >>> the asset.
>> >>>
>> >>> -cheers
>> >>> -meadhbh
>> >>> --
>> >>> meadhbh hamrick * it's pronounced "maeve"
>> >>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Sep 20, 2010 at 2:55 PM, Morgaine
>> >>> <[e-mail]> wrote:
>> >>> > Barry, I too think that we are arguing something that we already
>> >>> > agree
>> >>> > on.
>> >>> > Joshua was undoubtedly right in his latest post, because after all
>> >>> > we've
>> >>> > spent hundreds of emails discussing interop between virtual worlds
>> >>> > in
>> >>> > very
>> >>> > explicit terms, so it's close to impossible that this hasn't been
>> >>> > our
>> >>> > common
>> >>> > goal.  It must be an issue of terminology or emphasis.
>> >>> >
>> >>> > I like the services approach to interop a lot, as it provides a high
>> >>> > degree
>> >>> > of decoupling and very natural client-server architectures with
>> >>> > which we
>> >>> > have huge experience in building and scaling.
>> >>> >
>> >>> > However, our VW use cases are not expressed in terms of services,
>> >>> > but in
>> >>> > terms of user-level concepts like virtual worlds, teleports,
>> >>> > avatars,
>> >>> > and
>> >>> > clothing.  Somehow we are going to have to examine our
>> >>> > services-oriented
>> >>> > definitions and protocols in terms of the VW-oriented use cases to
>> >>> > determine
>> >>> > whether we are on the right track and fulfilling our requirements.
>> >>> > This
>> >>> > requires us to accept that interop between VWs must be discussable,
>> >>> > at
>> >>> > least
>> >>> > when examining use cases.
>> >>> >
>> >>> > I'm happy to accept that the bulk of our work will be in terms of
>> >>> > services,
>> >>> > as long as the general goal of providing interop between virtual
>> >>> > worlds
>> >>> > is
>> >>> > clearly highlighted in the introduction.  Without that, readers will
>> >>> > simply
>> >>> > have no idea what we're trying to achieve.  Besides that, we will
>> >>> > have
>> >>> > to
>> >>> > continue discussing how services relate to VWs (as we have been for
>> >>> > many
>> >>> > months), because that provides us with our user-level requirements.
>> >>> >
>> >>> > Beyond that, I think we can stick to the services view entirely.
>> >>> >
>> >>> >
>> >>> > Morgaine.
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > ===========================================
>> >>> >
>> >>> > On Mon, Sep 20, 2010 at 10:08 PM, Barry Leiba
>> >>> > <[e-mail]> wrote:
>> >>> >>
>> >>> >> Putting a finer point on what Joshua said:
>> >>> >>
>> >>> >> >> On Mon, Sep 20, 2010 at 4:27 PM, Jonathan Freedman
>> >>> >> >> <[e-mail]>
>> >>> >> >> wrote:
>> >>> >> >> From what I can tell the drafts do support interoperability
>> >>> >> >> between
>> >>> >> >> the
>> >>> >> >> same *class* of virtual world. The catch is that the language
>> >>> >> >> needs
>> >>> >> >> to
>> >>> >> >> be
>> >>> >> >> significantly clearer.
>> >>> >> >
>> >>> >> > The group's goals are formally described in the charter:
>> >>> >> > https://datatracker.ietf.org/wg/vwrap/charter/
>> >>> >> > ... which, based on previous iterations of this discussion, we
>> >>> >> > carefully
>> >>> >> > crafted to not try and nail down what a "virtual world" was so as
>> >>> >> > not
>> >>> >> > to
>> >>> >> > offend those who have an investment in any particular reading of
>> >>> >> > that
>> >>> >> > term.
>> >>> >>
>> >>> >> Indeed, and I think we are largely arguing about something we agree
>> >>> >> on, and, as Meadhbh and others have said, are stuck on the
>> >>> >> language.
>> >>> >> If we can get to the point where we *do* agree that the issue is
>> >>> >> just
>> >>> >> (or mostly) language, we can work on sorting out the language, and
>> >>> >> get
>> >>> >> un-stuck.
>> >>> >>
>> >>> >> As I understand the charter and the discussion leading up to it,
>> >>> >> we're
>> >>> >> arguing about what we *mean* by "virtual world".  Some want
>> >>> >> "multiple
>> >>> >> virtual worlds" to interoperate using vwrap; others are *defining*
>> >>> >> a
>> >>> >> single virtual world as the set of *regions* that interoperate
>> >>> >> using
>> >>> >> vwrap.
>> >>> >>
>> >>> >> I suggest that these are saying the same thing, that (in this
>> >>> >> regard,
>> >>> >> at least) we have the same goal, and that these two definitions
>> >>> >> largely collapse into one.
>> >>> >>
>> >>> >> Am I wrong, here?
>> >>> >>
>> >>> >> Barry, as chair
>> >>> >> _______________________________________________
>> >>> >> vwrap mailing list
>> >>> >> [e-mail]
>> >>> >> https://www.ietf.org/mailman/listinfo/vwrap
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > vwrap mailing list
>> >>> > [e-mail]
>> >>> > https://www.ietf.org/mailman/listinfo/vwrap
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>