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

[Morgaine <[e-mail]>]

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

>
> well. we did actually list a document called 'Avatar Format' in the
> group charter.
>
> i honestly don't know where morgaine go the idea we weren't going to work
> on it.



I've looked through my various postings and I can't see what that's in
reference to at all.  But speaking generally ...

It sounds to me like you're confusing the *VWRAP protocol* with *VWRAP
services* here.  They're very distinct!

The VWRAP protocol itself (or what I've been calling the "*core protocol*")
is just a service orchestrator, and it certainly shouldn't know anything
about the nitty gritty of rezzing avatars nor making their assets available
--- we have services in our model for handling such specific tasks with high
scalability and with the ability to evolve.  If the core protocol had the
details of avatar rezzing built it, it would very rapidly become obsolete.
We're factoring out low level tasks into replaceable services in order to
avoid that.  It's part of our protocol extensibility.

It doesn't even make sense to ask whether the whole ensemble of VWRAP core
protocol and all services would handle avatar rezzing.  With all the
services included, it's meant to provide a complete world system of the kind
we run today in SL or OpenSimulator, not a partial one!  How could it not
implement something as basic as avatar rezzing?

While I'm not sure where the question actually arose, if I said that avatar
rezzing was not done then we must have been talking about the VWRAP
*core*protocol, since no other interpretation really makes sense.
(But please
show me where I said this so I can confirm.)  And it's true.  The core
protocol should deal only with service orchestration.

We haven't really developed a naming system for our services, so our
references to them have always been somewhat sloppy, and what you mention
above seems to have been an artifact of this.

We have this really nice concept of a VWRAP protocol (I seem to be the only
one calling it the VWRAP "*core protocol*") plus a constellation of services
that it orchestrates.  This gives us great decoupling, easy evolution,
scalability because the services are web services and also because the
number of services is itself variable, and it offers great flexibility in
deployment patterns through service choices and service location choices.
And then after all that nice decomposition, apparently we call every part of
it "VWRAP" without the ability to distinguish the core protocol from the
services.  That's not very useful.

I suggest we call our main protocol VWRAP.Core, and our services
VWRAP.Inventory, VWRAP.Asset, VWRAP.Region, VWRAP.Teleport, VWRAP.Avatar,
and so on to cover all the services required by a world.  (And our documents
should be laid out to match.)  VWRAP.Core would be the core protocol that
engages all the others as optional services.  Then we could cleanly state
that VWRAP.Core just glues services together, and that when a teleport is
requested it engages VWRAP.Region, VWRAP.Teleport, VWRAP.Avatar, and any
other services needed for completion of a teleport.

Currently our descriptions are not very self-explanatory and seem to be
causing ambiguity because we have no official means of naming the various
parts.


Morgaine.





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

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

> On Wed, Sep 22, 2010 at 1:30 PM,  <[e-mail]> wrote:
>
> > It is really true that VWRAP will not have a specification on the avatar.
> >  How can one avatar go to another space without that?  How will I know
> how
> > to expose my avatar to another space without it?
>
> well. we did actually list a document called 'Avatar Format' in the
> group charter.
>
> i honestly don't know where morgaine go the idea we weren't going to work
> on it.
>
> however... other people are working on avatar format standards, it's
> entirely within the realm of possibility that this group may decide
> simply to adopt a format defined by another standards development
> organization
>