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

[Morgaine <[e-mail]>]

The whole idea in the VWRAP model is to allow new services to be added and
changed very easily.  Requiring a new group charter, a new protocol features
list, and 2-year delay for a new WG iteration just to add some new services
is most definitely not the idea behind VWRAP! :-)

I reject that suggestion and the continual rechartering for new services
completely.


Morgaine.




===============================

On Wed, Sep 22, 2010 at 3:47 PM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> yeah. i see your point morgaine.
>
> but... (yes, there's always a "but")
>
> those of us who will be implementing these specs are likely interested
> in (as david calls it) "boiling the ocean one thimble at a time."
>
> it's important to realize that if we recharter with a very small list
> of features, we can then very easily recharter later to include more
> of the problem domain.
>
> maybe there's room for a couple documents... one that's like "this is
> where we eventually want to get to" and that would be the one where we
> all throw our eventual use cases in.
>
> then every couple of years we carve off another set of functionality.
>
> i believe barry can confirm that it's possible to recharter groups and
> that it's WAAAY easier to add functionality to a group's charter than
> to remove it.
>
> i'm mildly concerned that we've blown waaaay past our document
> deadlines, and in large part the reason seems to be we keep
> antagonizing each other about scope.
>
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Wed, Sep 22, 2010 at 7:34 AM, Morgaine
> <[e-mail]> wrote:
> > The general idea in VWRAP was to neither prescribe nor proscribe any
> > particular set of services, but it's certainly important to enumerate,
> and
> > to define the hooks to handle, all the common service options, otherwise
> as
> > Mike says, worlds are not going to be very interesting.
> >
> > Anything that we do today in SL and in Opensim-type worlds deserves to be
> on
> > the list, and different developers will no doubt implement different sets
> of
> > them in accordance with their needs and interests.  All the ones
> mentioned
> > here are reasonable, but we need to add several more.
> >
> > Being listed means merely that someone can implement it if they want to
> as a
> > demo VWRAP service, not that it's mandatory.  Even stub implementations
> are
> > helpful, and will help us to test out concepts.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> > ==============================
> >
> > On Wed, Sep 22, 2010 at 2:39 PM, 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
> >
> >
>