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

[Meadhbh Hamrick <[e-mail]>]

Christina,

you may be adding a bit more to my message than is really there. i
don't want you and morgaine to "go away." i want you to stay engaged
here, but this is a group that talks about wire protocols, and the
suggestion that we try to standardize a client state model may be a
bit out of scope.

the IEEE and MPEG are working on VW standards that are much more
expansive, that might be a better forum for things like client models.

i want people who are working on such things to tell us what they
need, without telling us we're doing the wire protocol piece wrong.

but...

we have a charter which specifies a "contract" with the IESG about
what we're on the hook to deliver. at some point we need to stop
increasing the scope of this group and actually deliver something.

-cheers
-meadhbh

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



On Wed, Sep 22, 2010 at 7:51 AM, Cristina Videira Lopes
<[e-mail]> wrote:
> 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
>
>