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

[Meadhbh Hamrick <[e-mail]>]

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