Re: [vwrap] Consensus? What exactly should be in the protocol

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

Meadhbh, most of your observations are completely off. But one is not: 
the one about some of us (well, me, at least) paying attention to the 
larger context of the protocols.

The thing to have in mind is that the Web is not just a protocol. It's a 
set of design principles for large-scale decentralized systems, as I 
explained in some previous email (extended version of it in one of our 
former grad student's PhD thesis: 
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). If we go 
and start hammering in protocols that go against those design 
principles, chances are those protocols are going to be completely 
ignored, because the design principles of the Web have proven to be 
extremely beneficial for diversity and scalability, and a lot of people 
simply aren't interested in giving up on the freedom that the Web design 
principles offer.

If interoperability of virtual worlds that use the Web design principles 
are out of scope of this group, I'll be glad to go elsewhere, because, 
as I said, that's my main interest in here.

Meadhbh Hamrick wrote:
> kk. i _think_ i'm sensing a pattern... people interested in a more
> expansive view of this effort seem to be interested in client
> behavior.
>
> some of us over on the "let's just do a protocol" side of the debate
> are fine to give only a small bit of guidance under the guise of
> "processing expectations."
>
> is this a fair statement?
>
> the obvious next place i'm going with this is to see if we can break
> the "client behavior" piece off and have it run by a different group
> (sort of like the IETF/W3C split with HTML5/HTTPbis.) the IETF has
> typically been a community focused on wire protocols. i don't want to
> diminish anyone's actual or potential contributions here, but it seems
> that Diva and Morgaine are interested in a much more expansive problem
> domain. i'm worried that this group and this organization is not
> equipped to properly address some of those issues.
>
> (and this is going to sound like i'm totally dissing Diva and
> Morgaine, but i'm actually not, just hear me out.) i'm just thinking
> that it might reduce friction if those of us interested in wire
> protocol worked on a wire protocol, while those people interested in
> specifying a product / project, etc. take those more expansive
> conversations to a forum more appropriate for their discussion.
>
> but the fact that people with a "more expansive" interest have landed
> here makes me wonder... what IS the forum for these more expansive
> discussions? i fear it doesn't really exist, and that's why we have
> such wide ranging discussions here.
>
> i have no problems with the things that Diva or Morgaine have posted,
> but at the end of the day, i'm not interested in defining a protocol
> that is SOLELY about rendering a virtual world. i would like my auth
> protocol to allow facebook and twitter groups to show up in my virtual
> world client. i would like a web app that (like XStreetSL) renders a
> virtual object on a web page, but i want that object to be rendered
> from data retrieved directly from the asset server.
>
> my fear is that as we start talking about state diagrams for virtual
> world clients and hard definitions of virtual worlds, we lose site of
> what this group was originally chartered for: to specify a wire
> protocol of sufficient specificity that software developers could
> write code that had a fighting chance to be interoperable.
>
> in the past i've made flip comments to morgaine of the effect... "if
> you're interested in talking about interop between virtual worlds,
> take the discussion to MMOX, where it belongs."
>
> but seriously... if we're interested in something more than a wire
> protocol, we may want to try to recharter.
>
> or at the very least, could we agree to move the discussion of "what
> is a virtual world" to the MMOX list? if we did that, i would promise
> to NEVER say anything about how discussions are out of scope on that
> list, ever.
>
> i'm proposing that we reserve the VWRAP list for discussions of the
> wire protocol while the MMOX list is more about "open ended"
> discussions. on MMOX, we could have extensive conversations about a
> more expansive problem domain with the view that consensus on that
> list could lead to a new charter on this one.
>
> and in the meantime, we could focus here on a very small subset of
> things like mike, john and i seem to be suggesting.
>
> just an idea.
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Wed, Sep 22, 2010 at 6:39 AM, Mike Dickson <[e-mail]> wrote:
>   
>>  On 09/22/2010 12:14 AM, Hurliman, John wrote:
>>     
>>> This is closer to what I had in my head for VWRAP. Start with the goal of
>>> a portable virtual world presence, and a couple of necessary services fall
>>> out of that:
>>>
>>> * Identity/Authentication
>>> * Assets (possibly Inventory, maybe)
>>> * Teleport (both login and simulation to simulation)
>>>
>>> Which will in turn require:
>>>
>>> * Type system
>>> * Capabilities/X.509/insert_security_here
>>> * Avatar file format?
>>> * Event queue?
>>>
>>> And leave everything else for VWRAP2. If we can standardize those services
>>> and meet that first goal it will be much easier to tackle things like
>>> friends or groups or avatar movement / state simulation or anything else. I
>>> don't know if there is any industry demand for a virtual world avatar
>>> movement RFC, but other people have different perspectives. I'm strongly in
>>> favor of working toward the portable virtual world presence and supporting
>>> service definitions first though.
>>>
>>> John
>>>       
>> I like this list for a first effort though it leaves alot unspecified and
>> from a user perspective a system that just implements to this level won't be
>> terribly exciting.  That doesn't mean that implementations can't fill in
>> extras (things like IM, currency, script compatability, etc may be
>> uninteresting to some but if your trying to implement a production system
>> they become important to the user experience pretty quickly).
>>
>> I think if we focus on John's list, identify how services decompose that
>> implement that and then specify that as VWRAP we'd have made a good initial
>> effort and can then move on to some of the more difficult issues.
>>
>> Mike
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>     
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>