Re: [vwrap] Status and future of the VWRAP working group

[Izzy Alanis <[e-mail]>]

I definitely agree that the charter reflect (define!) our goals... but
what are those goals?

I prefer to read the existing charter as very ambitious. Trying ...
not to bridge existing worlds, but allow for the creation of new
worlds in which new things are possible. But the rest of the
documentation is littered with implementation details about the
existing virtual worlds.

It's the pull and tug between breaking free with new ideas (and,
Morgaine, you have a lot of cool new ideas) and being tied to the
existing infrastructure that's at conflict here.

When I say that the existing charter was salvageable, I mean this: If
we're going to follow that ambitious goal and forge ahead (possibly
leaving the existing virtual worlds behind)... then yeah, I think we
can work under this charter.  If we need to step back and rein in our
ambition (focus on interoperability and asset sharing between existing
virtual worlds?), then the charter should reflect that to give the
group focus.


On Sun, Mar 27, 2011 at 8:17 PM, Morgaine
<[e-mail]> wrote:
> I think I may have unconconsciously been evading the question of
> rechartering up to now, possibly because it was and is such a pain point.
> No more evading though, if we want to get something done.
>
> Re-chartering seems inevitable to me, because the existing charter failed so
> very dramatically to guide us towards the requirement that we recently made
> explicit, namely interoperation between virtual worlds.
>
> I'm not too surprised at that failure, since it has been very clear from the
> start that everybody except the main sponsoring companies expected interop
> between virtual worlds to materialize from our work.  Consequently, I could
> see the problem coming our way once the realization that it wasn't on the
> agenda finally hit home more widely.  Crista did us a great service by
> triggering that understanding within the group.
>
> Armed with that understanding now, it is easy to see how the charter sold us
> a bridge.  After all, nowhere does it state that the goal is interoperation
> between virtual worlds, so it has been wishful thinking alone that made so
> many people expect otherwise.  While it mentions asset services being run by
> more than one organization, it never stated that these asset services could
> serve multiple virtual worlds and hence act as the essential bridge for
> interop of assets between them.  Again, it was just wishful thinking that
> made some people interpret it that way, but as we now know, it was not the
> design goal.
>
> There are many such occurrences in the charter.  It seems to vaguely use the
> language of interop, but only in respect of growing virtual worlds by adding
> regions to them (ie. it's an intra-world protocol, not inter-world).  It
> does not offer anything to allow such virtual worlds to interoperate in the
> way most people expect, for example supporting virtual tourism between them.
>
> Since the charter does not expressly state what we want, it is incorrect, or
> worse, misdirecting.
>
> I see no alternative to rechartering if we expect the outcome to be interop
> between virtual worlds.  If we do not recharter, it will not describe our
> goals, and it will not be meaningful to other readers.
>
>
> Morgaine.
>
>
>
>
> ==================================
>
> On Sun, Mar 27, 2011 at 3:37 PM, Vaughn Deluca <[e-mail]>
> wrote:
>>
>> Morgaine,
>>
>> All very well, but you did not answer Izzy's question about rechartering.
>> I agree with Izzy that it is by no means clear that the current
>> charter is unsalvageable.
>>
>> For instance, your post below you write:
>> >All we really need are shared asset services that are independent of the
>> > world providers.
>>
>> I my view this is square within the current charter were it says:
>>
>> "Within a VWRAP virtual environment, services may be deployed by
>> multiple organizations having varying policies and trust domains."
>>
>> I have always read that as meaning that an inventory could be
>> *anywhere* and owned by *anybody*, and that surely covers my own
>> client side inventory as well (possibly implemented as a personal
>> asset service running on my own machine?)
>>
>> The decision to have server side inventory is clearly the choice of
>> that servers operator, and it is my chose use that inventory if that
>> suits me.  If client side inventory is superior that will become clear
>> by users preferring to use it. I fail to see  how our current approach
>> is an obstacle on this path.
>>
>> Can you point out what part of the charter needs to be changed, or
>> better make a proposal for that change so we have something concrete
>> to work from?
>>
>> I strongly feel we need to build some consensus in this group, and to
>> do so we need to be crystal clear about our aims. We should start
>> front be very top. You had a first attempt at restructuring the intro
>> document, but we need to address the charter first. My view is that it
>> is not yet needed to change that, and if you feel different this is
>> the time to say so.
>>
>> -- Vaughn
>>
>> On 3/27/11, Morgaine <[e-mail]> wrote:
>> > Indeed, server-side inventories are one of the worst design decisions of
>> > the
>> > existing implementations.
>> >
>> > They give us no end of problems, such as the impossibility of high-speed
>> > client-side searching and regular lag issues, not to mention being
>> > non-portable because each world provider would implement them
>> > differently.
>> > They're also non-scalable because they're centralized, and non
>> > supportive of
>> > VW tourism because a given world provider would control what can be put
>> > into
>> > them, instead of the traveling user being in control.
>> >
>> > Inventories need to be client-side (I refer to the trees of asset
>> > metadata,
>> > not the asset data, in case that's not clear), with an auto sync of
>> > deltas
>> > to a configured asset service for resilience/backup.  That way only
>> > those
>> > people who do not look after their local inventory resources will suffer
>> > client-server transport lag to recreate them, and the full power of
>> > client-side CPUs and client-side databases and scripting can be deployed
>> > to
>> > make inventories a real powerhouse.
>> >
>> > All we really need are shared asset services that are independent of the
>> > world providers.  That alone is enough to virtually ensure portability,
>> > interoperability, and scalability, as long as a lightweight protocol can
>> > be
>> > found that is also extensible to support tomorrow's worlds.  Making a
>> > standard to support only what we're doing today isn't particularly
>> > interesting.
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> >
>> > ==================================
>> >
>> > On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol <[e-mail]>
>> > wrote:
>> >
>> >> If there was focus only on the login (agent domain) and inventory
>> >> services,
>> >> then I think we will get some where.
>> >>
>> >> Yes, we know there are issues with inventory that are already in the
>> >> simulator side, so this is the suggestion to build apart from those
>> >> issues.
>> >> Start from there.
>> >>
>> >>
>> >>
>> >> Izzy Alanis wrote:
>> >>
>> >>> Are you suggesting a re-charter around shared services only?
>> >>> Or that we shift the deliverables to push that to the forefront? (In
>> >>> which case, we still really do need an intro doc and to address the
>> >>> messaging semantics)
>> >>>
>> >>> I'm not quite convinced that the charter is unsalvageable. I think the
>> >>> last rev of the intro has a lot of good things in it too -- lots I
>> >>> would like to see changed, but good stuff too.
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine
>> >>> <[e-mail]> wrote:
>> >>>
>> >>>
>> >>>> I'm glad to see some renewed participation here!� Perhaps the threat
>> >>>> of
>> >>>> death sharpens the mind. ;-)
>> >>>>
>> >>>> Since there seems to be some fresh thinking in the air, I am going to
>> >>>> add
>> >>>> two short points to the discussion.� The first is a matter of
>> >>>> procedure,
>> >>>> and
>> >>>> the second is related to our technical direction:
>> >>>>
>> >>>> Notwithstanding that the IETF places certain duties on Barry and
>> >>>> others
>> >>>> to
>> >>>> ensure that there is visible progress in the form of documents, I
>> >>>> must
>> >>>> say
>> >>>> that "documents at all costs" is not a particularly good way of
>> >>>> achieving
>> >>>> technical progress.� It's the "documents at all costs" push that gave
>> >>>> us
>> >>>> several documents previously, only one of which turned out to be
>> >>>> usable
>> >>>> for
>> >>>> interoperation between VWs.� Documents churned out before there is
>> >>>> agreement
>> >>>> on goals and direction are a hindrance to the process, not an
>> >>>> indicator
>> >>>> of
>> >>>> progress, and they waste everyone's time.� Progress is certainly not
>> >>>> a
>> >>>> matter of just putting pen to paper, as has been suggested.� Far from
>> >>>> it.
>> >>>> First we must agree as a group on how a given protocol is going to
>> >>>> meet
>> >>>> our
>> >>>> goals, and drafts then present that formally with hard technical
>> >>>> details
>> >>>> added.� Done the other way around just results in much angst and
>> >>>> wasted
>> >>>> effort, as happened here.
>> >>>>
>> >>>> Given the almost unanimous agreement that crystallized around
>> >>>> Crista's
>> >>>> thread of a few months ago which could be paraphrased as "The VWRAP
>> >>>> documents do nothing for interop between virtual worlds", I would
>> >>>> like
>> >>>> to
>> >>>> suggest that instead of continuing to beat the dead horse of OGP that
>> >>>> we
>> >>>> still have on our hands, why don't we focus on delivering something
>> >>>> that
>> >>>> is
>> >>>> actually usable by compatible groups like Opensim and realXtend and
>> >>>> iED?
>> >>>> There is a nugget of gold at the heart of the VWRAP concept which can
>> >>>> provide exactly that:� the idea of shared asset services, and a
>> >>>> protocol
>> >>>> for
>> >>>> accessing them.
>> >>>>
>> >>>> There is a huge amount of activity in our sector of the virtual
>> >>>> worlds
>> >>>> community.� There is also no end of interest in interoperation, but
>> >>>> the
>> >>>> trouble seems to be that each group is rather narrowly focused on
>> >>>> their
>> >>>> own
>> >>>> particular code base.� Where I think a group such as ours can
>> >>>> contribute
>> >>>> is
>> >>>> by providing a lightweight protocol which is easily used by all,
>> >>>> without
>> >>>> the
>> >>>> previous baggage.� Simple problems demand simple solutions, and while
>> >>>> a
>> >>>> massively scalable shared asset service is not exactly simple, it is
>> >>>> nevertheless a lot simpler than the much larger task that we had set
>> >>>> ourselves previously.
>> >>>>
>> >>>> Perhaps that would be a good place to start, afresh.
>> >>>>
>> >>>>
>> >>>> Morgaine.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> =====================================
>> >>>>
>> >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba
>> >>>> <[e-mail]>
>> >>>> wrote:
>> >>>>
>> >>>>
>> >>>>> Reminder: If anyone's done anything related to what's below, please
>> >>>>> post here and get some discussion going. �There's still about two
>> >>>>> and
>> >>>>> a half weeks to get something ready.
>> >>>>>
>> >>>>> Barry, as chair
>> >>>>>
>> >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba
>> >>>>> <[e-mail]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba
>> >>>>>> <[e-mail]>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> As for timescales, we already started work on a new Intro in
>> >>>>>>> October
>> >>>>>>>> and
>> >>>>>>>> November, as I described in my first email in this thread.� It
>> >>>>>>>> was
>> >>>>>>>> being
>> >>>>>>>> done informally, not as an official draft but as input to a
>> >>>>>>>> totally
>> >>>>>>>> new
>> >>>>>>>> draft.� It was not being done as a revision because the previous
>> >>>>>>>> Intro
>> >>>>>>>> simply did not meet key requirements for many contributors, as
>> >>>>>>>> was
>> >>>>>>>> clear
>> >>>>>>>> from the group's very intense discussions of September.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Can you see if you can get it into reasonable shape to introduce
>> >>>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ?
>> >>>>>>> �That
>> >>>>>>> would give people something concrete to work from.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> I haven't seen any activity on this, so let me repeat this with a
>> >>>>>> deadline:
>> >>>>>>
>> >>>>>> The chairs ask the proponents to please get a new intro document
>> >>>>>> into
>> >>>>>> reasonable (not final) shape to introduce publicly, and to submit
>> >>>>>> it
>> >>>>>> as an Internet Draft with a name like
>> >>>>>> "draft-SOMEONE-vwrap-intro-00"
>> >>>>>> by 10 April (the significance of which will be left for the reader
>> >>>>>> to
>> >>>>>> research, should s/he care to). �There may, of course, be any
>> >>>>>> (reasonable) number of authors listed on the draft, and any one may
>> >>>>>> be
>> >>>>>> the name chosen to live in the draft name.
>> >>>>>>
>> >>>>>> If we're not able to do that, I think we need to seriously question
>> >>>>>> whether there's enough real energy to continue.
>> >>>>>>
>> >>>>>> Barry, as chair
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> vwrap mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/vwrap
>> >>>>>
>> >>>>>
>> >>>> _______________________________________________
>> >>>> vwrap mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/vwrap
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>> _______________________________________________
>> >>> vwrap mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/vwrap
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> --- https://twitter.com/Dzonatas_Sol ---
>> >> Web Development, Software Engineering, Virtual Reality, Consultant
>> >>
>> >>
>> >
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>