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

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 <mike.dickson@hp.com> 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
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>