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

[Meadhbh Hamrick <[e-mail]>]

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
>