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

[Cristina Videira Lopes <[e-mail]>]

Maybe I'm missing something, please tell me what it is.

The way people here have been talking about single service deployment,  
it looks like it's something that fundamentally affects the underlying  
interop protocols. It looks to me that it isn't so; it's only  
fundamental if you reinvent it.

For simplicity sake, let's assert that a virtual world is  
indistinguishable from a web application running on a web site, ok? --  
literally, now that HTML5 is here. A web site is under one single  
authority, even if it uses services from other organizations.

There can be independent services for VWs, just like there is, say,  
S3. I don't think we need to reinvent anything for that. I mean, we  
can reinvent, but we really don't have to, the Web already has it;  
that reinvention is an additional piece of intellect that, if not done  
carefully, may hinder, rather than help, integration with what already  
exists.

If you want to tell the client to call web services directly, like the  
capability URLs model suggests, that's ok too. Usually the web browser  
isn't allowed to do that. Now there is CORS, so now it can do that.  
CORS is a way for the web app to place data/computation in the user's  
machine without having to proxy it. Ultimately, it's a choice on the  
part of the web app, and the services that it uses; it's not imposed  
by any protocol for service-level interoperability on the web!

So why is single service deployment so important for VW  
interoperability? What am I missing?


On Sep 20, 2010, at 4:17 PM, Meadhbh Hamrick 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