wrote= : > I=92m considering a change in the C# LLSD implementation > (OpenMetaverse.StructuredData) to skip serialization of default values > inside maps. For example, the following structure: > > > > { > > =93zero=94:0, > > =93one=94:1, > > =93empty_string=94:=94=94, > > =93hello_string=94:=94hello world=94 > > } > > > > Would become: > > > > { > > =93one=94:1, > > =93hello_string=94,=94hello world=94 > > } > > > > From my reading of the draft (and our current implementation), those two > serializations should be equivalent. Do the current Linden Lab > implementations handle that correctly? The only problem I see with the C# > implementation is that it would make some incompatible typecasts work whe= n > they shouldn=92t. For example, the receiving end could then read key =93z= ero=94 as > an LLSD array and it would work, where the value =930=94 usually shouldn= =92t be > convertible to an array. So it assumes some level of coherence between th= e > sender and receiver, which I think is acceptable. > > > > I would look at the source of the other implementations myself, but the > last time I checked the PHP implementation was sorely out of date and the > C++ implementation was not under a liberal license. > > > > John > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --001485f6cff8561b470479c53585 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable i'm not absolutely sure all our legacy SL interfaces do this right now,= but i do know that we want them too. future VWRAP work will definitely hav= e those semantics.

it may be advantageous to have that b= ehavior be a configurable parameter, then fire it up, and see what breaks. = we could then use the failure logs to track down interfaces that don't = follow the "you get the default if it's not there" semantics.=

-cheers

-meadhbh
--
=A0 = infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced "mae= ve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden=

On Wed, Dec 2, 2009 at 12:19, Hurliman, = John <john.= hurliman@intel.com> wrote:

I=92m considering a change in the C# LLSD implementa= tion (OpenMetaverse.StructuredData) to skip serialization of default values insi= de maps. For example, the following structure:

=A0

{

=A0=A0=A0 =93zero=94:0,

=A0=A0=A0 =93one=94:1,

=A0=A0=A0 =93empty_string=94:=94=94,

=A0=A0=A0 =93hello_string=94:=94hello world=94

}

=A0

Would become:

=A0

{

=A0=A0=A0 =93one=94:1,

=A0=A0=A0 =93hello_string=94,=94hello world=94

}

=A0

From my reading of the draft (and our current implementation), those two serializations should be equivalent. Do the curr= ent Linden Lab implementations handle that correctly? The only problem I see wi= th the C# implementation is that it would make some incompatible typecasts wor= k when they shouldn=92t. For example, the receiving end could then read key = =93zero=94 as an LLSD array and it would work, where the value =930=94 usually shouldn=92t be convertible to an array. So it assumes some level of coherence between the sender and receiver, which I think is acceptable.

=A0

I would look at the source of the other implementati= ons myself, but the last time I checked the PHP implementation was sorely out of date a= nd the C++ implementation was not under a liberal license.

=A0

John

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001485f6cff8561b470479c53585-- From lenglish5@cox.net Wed Dec 2 21:37:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D25F3A67D2 for ; Wed, 2 Dec 2009 21:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUAJcIKo2j7w for ; Wed, 2 Dec 2009 21:37:29 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id 967B13A67AE for ; Wed, 2 Dec 2009 21:37:26 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao101.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091203053718.UBYY16492.fed1rmmtao101.cox.net@fed1rmimpo02.cox.net>; Thu, 3 Dec 2009 00:37:18 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo02.cox.net with bizsmtp id CVdJ1d0012l1Ksg04VdJKX; Thu, 03 Dec 2009 00:37:18 -0500 X-VR-Score: -200.00 X-Authority-Analysis: v=1.1 cv=hBBxVKrpT8NIO1i2+E6jIs4z/JDusIBXnpwMe9ND0ls= c=1 sm=1 a=8GY0_Vv1CH0A:10 a=Wajolswj7cQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=pD2KqRnHSLzkJ_yizp0A:9 a=V0pFv12u1L_6q2GZ5wEA:7 a=T08U2qt3X6ZfPtScJRKvSOQNFxwA:4 a=dGJ0OcVc7YAA:10 a=lZB815dzVvQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4B174E8D.9060306@cox.net> Date: Wed, 02 Dec 2009 22:37:17 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Infinity Linden (Meadhbh Hamrick)" References: <62BFE5680C037E4DA0B0A08946C0933D99B9116B@rrsmsx506.amr.corp.intel.com> <3a880e2c0912021303q2601313gc72db2758d65343c@mail.gmail.com> In-Reply-To: <3a880e2c0912021303q2601313gc72db2758d65343c@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "ogpx@ietf.org" Subject: Re: [ogpx] (Not) serializing LLSD default values X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 05:37:30 -0000 Infinity Linden (Meadhbh Hamrick) wrote: > i'm not absolutely sure all our legacy SL interfaces do this right > now, but i do know that we want them too. future VWRAP work will > definitely have those semantics. > > it may be advantageous to have that behavior be a configurable > parameter, then fire it up, and see what breaks. we could then use the > failure logs to track down interfaces that don't follow the "you get > the default if it's not there" semantics. > > this might over-complicate things, but could it be possible to have contextual defaults? Lawson > > On Wed, Dec 2, 2009 at 12:19, Hurliman, John > wrote: > > I�m considering a change in the C# LLSD implementation > (OpenMetaverse.StructuredData) to skip serialization of default > values inside maps. For example, the following structure: > > > > { > > �zero�:0, > > �one�:1, > > �empty_string�:��, > > �hello_string�:�hello world� > > } > > > > Would become: > > > > { > > �one�:1, > > �hello_string�,�hello world� > > } > > > > From my reading of the draft (and our current implementation), > those two serializations should be equivalent. Do the current > Linden Lab implementations handle that correctly? The only problem > I see with the C# implementation is that it would make some > incompatible typecasts work when they shouldn�t. For example, the > receiving end could then read key �zero� as an LLSD array and it > would work, where the value �0� usually shouldn�t be convertible > to an array. So it assumes some level of coherence between the > sender and receiver, which I think is acceptable. > > > > I would look at the source of the other implementations myself, > but the last time I checked the PHP implementation was sorely out > of date and the C++ implementation was not under a liberal license. > > > > John > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > ------------------------------------------------------------------------ > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From john.hurliman@intel.com Thu Dec 3 18:32:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617E03A6403 for ; Thu, 3 Dec 2009 18:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTecmjhMExcn for ; Thu, 3 Dec 2009 18:32:13 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 955B03A68AF for ; Thu, 3 Dec 2009 18:32:10 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 03 Dec 2009 18:31:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,339,1257148800"; d="scan'208";a="472743638" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 03 Dec 2009 18:31:57 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Thu, 3 Dec 2009 19:32:00 -0700 From: "Hurliman, John" To: "ogpx@ietf.org" Date: Thu, 3 Dec 2009 19:31:53 -0700 Thread-Topic: [ogpx] (Not) serializing LLSD default values Thread-Index: Acpz2q6WgNrRa0/BRMCQ6Vu2E8SZtQArq2dw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D9C22D970@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D99B9116B@rrsmsx506.amr.corp.intel.com> <3a880e2c0912021303q2601313gc72db2758d65343c@mail.gmail.com> <4B174E8D.9060306@cox.net> In-Reply-To: <4B174E8D.9060306@cox.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ogpx] (Not) serializing LLSD default values X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 02:32:14 -0000 I don't think so, because the sending side and receiving side don't necessa= rily share any context. John -----Original Message----- From: Lawson English [mailto:lenglish5@cox.net]=20 Sent: Wednesday, December 02, 2009 9:37 PM To: Infinity Linden (Meadhbh Hamrick) Cc: Hurliman, John; ogpx@ietf.org Subject: Re: [ogpx] (Not) serializing LLSD default values Infinity Linden (Meadhbh Hamrick) wrote: > i'm not absolutely sure all our legacy SL interfaces do this right=20 > now, but i do know that we want them too. future VWRAP work will=20 > definitely have those semantics. > > it may be advantageous to have that behavior be a configurable=20 > parameter, then fire it up, and see what breaks. we could then use the=20 > failure logs to track down interfaces that don't follow the "you get=20 > the default if it's not there" semantics. > > this might over-complicate things, but could it be possible to have=20 contextual defaults? Lawson > > On Wed, Dec 2, 2009 at 12:19, Hurliman, John > wrote: > > I'm considering a change in the C# LLSD implementation > (OpenMetaverse.StructuredData) to skip serialization of default > values inside maps. For example, the following structure: > > =20 > > { > > "zero":0, > > "one":1, > > "empty_string":"", > > "hello_string":"hello world" > > } > > =20 > > Would become: > > =20 > > { > > "one":1, > > "hello_string","hello world" > > } > > =20 > > From my reading of the draft (and our current implementation), > those two serializations should be equivalent. Do the current > Linden Lab implementations handle that correctly? The only problem > I see with the C# implementation is that it would make some > incompatible typecasts work when they shouldn't. For example, the > receiving end could then read key "zero" as an LLSD array and it > would work, where the value "0" usually shouldn't be convertible > to an array. So it assumes some level of coherence between the > sender and receiver, which I think is acceptable. > > =20 > > I would look at the source of the other implementations myself, > but the last time I checked the PHP implementation was sorely out > of date and the C++ implementation was not under a liberal license. > > =20 > > John > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > ------------------------------------------------------------------------ > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > =20 From lenglish5@cox.net Fri Dec 4 06:44:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0583A6A25 for ; Fri, 4 Dec 2009 06:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SiST5FfEbUm for ; Fri, 4 Dec 2009 06:44:29 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id DC0CA28C0E6 for ; Fri, 4 Dec 2009 06:44:27 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091204144419.UMZD11920.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>; Fri, 4 Dec 2009 09:44:19 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo01.cox.net with bizsmtp id D2kH1d00P2l1Ksg032kJuD; Fri, 04 Dec 2009 09:44:18 -0500 X-VR-Score: -270.00 X-Authority-Analysis: v=1.1 cv=QnsHyrXODU/M8PFHjoaSY8vWw/wnc68pWh1cXI7OZ58= c=1 sm=1 a=Wajolswj7cQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=xqzR1eaSAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=774agy78hMV2aJ1gbC4A:9 a=ZFm3eOwHhSsZiJ8oo-sA:7 a=mLR-b7ftvITM0tHz7qGZ8M8AuD4A:4 a=PvCTlul6mIQA:10 a=5_Qf--nH2aYA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4B192041.1060505@cox.net> Date: Fri, 04 Dec 2009 07:44:17 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Meadhbh Hamrick References: <9b8a8de40911290542l3f6ff7a4pd00a9d5337a04962@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP still alive? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:44:30 -0000 It strikes me that LLSD might be extended for specific issues beyond what it was originally intended for. E.G. http://ligwww.epfl.ch/%7Eaguye/AML/AMLOverview.pdf within each specialized context, perhaps there can be default values assumed without the requirement of some kind of dtd or perhaps a 4/8 character, DTD type might be made part of some future extension ala Apple's old type/creator codes. Lawson Meadhbh Hamrick wrote: > yes, VWRAP _is_ still alive. > > we're currently working on three documents: LLSD / LLIDL, Intro and > Requirements, and Assets > > * LLSD / LLIDL > > LLIDL was in the middle of getting a well deserved face lift when > multiple, conflicting changes forced us to return to agreeing on the > problem definition instead of pushing out a draft. LLIDL / LLSD draft > development has been being informed by several pairwise / intense > descussions involving investigation of specific use cases. i hope to > get a wiki page up describing proposed changes at the end of this > week. > > but essentially what we're looking at is thus: > > - peeps didn't grok why LLSD has the "you get the default value when > you read a map key that's not there" semantics, so i'm integrating the > "structure and interpretation of LLSD messages" email into the draft > as motivation for why LLSD is needed. ( > http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html ) > > - peeps thought the LLIDL syntax was odd, that it didn't look "Cish > enough." i'm developing a proposal for making LLIDL look more like an > ALGOL derived language so C/C++/C#/Java programmers can look at it and > have a more immediate understanding of what it's doing. > > - we want to be able to support GETs as well as POSTs when LLSD is > carried over HTTP(S). this is so we an make use of intermediaries like > caching squid servers. so we're working on a way to map a resource > definition to a GET instead of a POST. i know there are some people > who want to carry LLSD over XMPP, so we're interested in avoiding > simply saying... "oh... just make this kind of message a GET" since > that's more of a HTTP(S) specific construction. > > - related to the item above, we're looking at ways to encode a request > as a query string. the idea here being that since some caching > intermediaries can cache two GET requests with the same URL, including > the query string, we want to be able to encode the request in the > query string to take advantage of the caching behavior. > > - some people thought that the variant syntax was confusing. > specifically, the relationship between a variant record and the > selector. (the selector is the element _in_ the variant map > declaration that has a literal value.) in other words, the way the > LLIDL parser knows that a particular variant is "valid" is that one of > the members of the map has a specific value. the relationship to the > variant and the selector was considered "haphazard" by some reviewers. > > - explaining the use of "late keys." i.e. - the '$' in some LLIDL > definitions. the use of the dollar sign ('$') in LLIDL as the key of a > map declaration indicates that there'll be a number of keys, the > symbol for each is determined at message send time, not at resource > definition time. > > - fixing things like broken XML DTDs. > > - changing the comment character from a semi-colon (';') to a hash mark ('#') > > * Intro and Goals > > There was a lot of commentary on the original "intro and requirements" > doc in Stockholm, and a trickle of interest since then. There are a > few minor changes to the draft, and the inclusion of a much better > glossary. David is writing a section on deployment patterns, and we > plan to integrate our changes "any day now." > > * Assets > > The Assets draft is in a much more "complicated" state. We're > coordinating our efforts with John Hurliman who's the lead developer > on the Cable Beach project. We hope that what will emerge will be a > unified protocol for accessing second life resources as cable beach > resources. > > -cheers > -meadhbh > > On Sun, Nov 29, 2009 at 5:42 AM, Vaughn Deluca wrote: > >> It has gotten terribly silent on the list, and its not hard to see why; >> without updates of the drafts the discussion floats free and people are >> bound to loose interest. >> I do understand that drafting these types of documents takes time, and too >> much discussion in an early stage sometimes only complicates matters, yet, a >> quick status update and maybe even a working version of the drafts in their >> current form would be nice to keep everybody synchronised... >> -Vaughn >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From han.sontse.sl@gmail.com Fri Dec 4 18:11:33 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A173A6818 for ; Fri, 4 Dec 2009 18:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya-vFGe93VPL for ; Fri, 4 Dec 2009 18:11:27 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 9D9013A63C9 for ; Fri, 4 Dec 2009 18:11:27 -0800 (PST) Received: by pwi20 with SMTP id 20so121212pwi.29 for ; Fri, 04 Dec 2009 18:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=h/v3/ieAzR+8xOaRvWf0KLvujU1XytH7iIOUU57cqEs=; b=bts/pT8yhIvBR2jmCq6iKbTr8K9+eBr1wSlydGAYfIxKB/Gj5mfsVAUM5Un0nbFoXz BUFmNCSIyv30UXinPSLlO/r6yRQYZli8Dc7DCtVWLns03If1mZwaNeF88m1tIoooxAGS y+4wmVruomkANYEdObvk3qAP1+siFcF5u0U90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=pM7QH7WFoBvmMBGNHcN/9dG9jaw79GhTCyC4wD/5SXRKkUX8bxdy1H5+Yvwg/Htb55 1o4cV7Ib/Ht7BYgZ3xFpfGOquiFnNNRbX+7EvhMg7NPzV1pDGnTLQYMQ9sub87/Sdtf6 oiIL6pL7zafs5j6ye0jFMf3nnS12ycE8+OYKo= Received: by 10.115.99.11 with SMTP id b11mr5331860wam.17.1259979073531; Fri, 04 Dec 2009 18:11:13 -0800 (PST) Received: from ?192.168.1.57? ([98.125.217.118]) by mx.google.com with ESMTPS id 23sm427913pxi.13.2009.12.04.18.11.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Dec 2009 18:11:12 -0800 (PST) Message-Id: <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> From: Han Sontse To: Carlo Wood In-Reply-To: <20091110204155.GA5757@alinoe.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-351513162 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 4 Dec 2009 18:11:10 -0800 References: <4AF8ECDE.2010900@cox.net> <20091110201157.GA10861@alinoe.com> <20091110204155.GA5757@alinoe.com> X-Mailer: Apple Mail (2.936) Cc: ogpx@ietf.org Subject: Re: [ogpx] Synchronization of gestures (was: Limits to interoperability of scripted objects) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 02:11:33 -0000 --Apple-Mail-1-351513162 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit My apologies to all for this screwed up thread. I didn't include the mail-host in the thread for the first part of this dialog. On Dec 4, 2009, at 12:42 PM, Carlo Wood wrote: > I know I'm not diplomatic, but you'll have to admit > that in some cases and/or for some people there IS a > need to wait till the slower ones have the data too. With all due respect, Carlo, I am finding that I disagree with your analysis. I have a lot of practical experience in SL getting animations as well as sound and textures to synchronize under a lot of different conditions by taking into account the client's existing cacheing behavior. I'm drawing on that experience for my assertions. I can't think of a single reasonable use case that would *require* clients to hold for the slowest link. The examples you have suggested don't require it to achieve the outcome you desire. The only reason that synchronization is a problem today in SL is because there is no provision for properly notifying the client that two or more isochronous assets are to be played as part of a sequence. Signaling the client that some arbitrary bundle of resources are required to be cached as a suite will handle a vast majority of the synchronization issues, and a MIDI-like sequence handler can manage the remainder of specialized cases where complex/strict client side isochronous behavior is desirable. The outlying cases (the unreasonable ones) are those that really are beyond the scope of what is possible because communication over any appreciable distances (> 100km ) is unlikely to ever be instantaneous in our life times. While wave fronts in electric media do travel near the speed of light, the switching fabric relaying and repeating those signals is several orders of magnitude slower even under the ideal cases. Inter- client isochronicity to the level a performing musician might desire is simply out of reach, since the ear-brain interface is sensitive to latencies as small as 2 to 5 ms, and acceptable performance almost completely breaks down at about >50 ms. So here I'll walk through an example... the hug: To synchronize a hug all that is needed is for the hug object to report that it contains bundled isochronous assets during the normal process of the client caching the surrounding area. This bundled sequence might include animation for the hugger and the huggee, and maybe a sound or two. It include possibly a client side script to move the target agents into the correct relative locations to participate in the hug. a) In the simple case the caching of bundled resources has occurred. b) A permissions request would be sent to the huggee. c) The permissions are granted. (were permission not granted a subsequent trigger event would be rejected by the SIM) d) The hugger's hug object issues a trigger event which is relayed through the Sim to all clients within audio/visual range. e) Each client on receiving the event applies the event to the indicated agents using the sequence bundle cached locally f) each client views the sequence isochronously as directed by the sequence bundle. Timing for the sequence is local to each client. Each client views the hug as a seamless sequence. Though the exact starting time of the event is different for each client. In all but the most extreme cases of lag, a user viewing the rendered event will have the perception that the event occurred simultaneously for all witnessing/participating agents. Ok now for a more complex case where one or more clients have not cached the bundle before the event is triggered: a) permission request is granted. b) The hugger's hug object issues a trigger event which is relayed through the Sim to all clients within audio/visual range. c) As each client receives the trigger event it may find that it must request the sequence bundle indicated in the event. The appropriate assets are requested. d) The sequence is played as soon as all the assets in the bundle are queued. e) Each client views the event as a seamless sequence. In this case the delay is likely to be longer for some clients than others. The exact wall clock delay does not matter since the end user has no idea when the event was actually sent. Users on extremely slow links may wish to have their client reject events that have become too stale, but this loss for one client has no impact on any other client witnessing the event. To avoid e) in the second example it might be desirable for a client to request sequence bundles right after caching agent appearances, to avoid experiencing excessively stale sequence triggers. ~HS~ --------------- To clarify my position: Key difference is that there really is no good reason for a client on a fast link to wait for the client on the slowest link before playing isochronous content locally. Ever! In 'live' performance situations there might be a need to send trigger events for sequences. (Trigger_sequence) However, there is no really good reason I can see to hold up the show because some clients are on slow links. Having clients signal readiness might be a useful *advisory*, to indicate to a program director that enough clients are fully cached to start a performance. This could be a simple broadcast to all clients requesting caching status on a *particular* bundle of pre-cacheable content. No automatic behavior, optional or otherwise, is needed for feedback. A scripted object might make such a broadcast and simply report each responder's findings to the program director. No client to client synchronization is needed for isochronous content. This is the key point I am making. There's no reason for the complexity you described: >>> * As soon as all viewers are ready (optionally, a parameter >>> of the original request includes a timeout after which >>> the delayed avatar is considered to have said "no"), >>> the server informs all viewers to start playing the >>> multi-gesture. ~HS~ On Dec 4, 2009, at 9:42 AM, Carlo Wood wrote: > Bottomline is, there should be an option (preferably the default > in the future) to wait a while until all needed assets are > downloaded, and then there needds to be a way to tell the other > clients (through the sim) that you are ready. > > I don't seem much difference there with your ideas :) > > Once all assets are ready (locally cached) then just playing > them in order as described by the gesture info will work > good enough: there is only one synchronization point needed: > when to START. > > On Fri, Dec 04, 2009 at 09:01:51AM -0800, Han Sontse wrote: >> I've been giving this a lot of thought recently. It seems to me >> that strict isochronous behavior between clients is not really >> needed for gestures and synchronous animations (dances and hugs). >> >> It doesn't really matter how long it takes a client to acquire the >> assets needed for a given interaction. Each client is showing a >> arbitrarily delayed rendition of the sim state anyway. >> >> It seems more useful to me to have a mechanism that describes a >> isochronous sequence using arbitrary collection of animated content; >> Audio, MIDI, animation, etc. A sequence time-line, if you will. >> The sequence lists the assets that will be played in the time line. >> These are then requested/located as needed by the client. Once all >> are queued, the sequence is played. From each client's perspective >> the script plays in local real time, but without any synchronization >> between clients. Tighter synchronization between clients could be >> achieved simply by having a mechanism for clients to be notified >> that sequenced objects are present in the local environment. The >> client can then choose to pre-cache these sequences subject to user >> preference. >> >> As the gesture mechanism operates today in SL, some content will >> begin playing as expected, while other content declared in the >> sequence are still loading. I do not know if this is as designed, >> or it reflects some collection of bugs in the gesture handling >> process. >> >> What is missing here is a robust method for notifying clients that >> isochronous groupings of content are present in the local >> environment. >> >> A more complex issue exists for situations where multiple clients >> seek to create a live interactive performance. The current state of >> the internet as a whole simply cannot support hard isochronous >> behavior. However a performing group at a physical location might >> cause a library of sequences to be cached in the clients, which can >> then be triggered by a tokenized sequence embedded in a QuickTime >> Stream. This choreography would then appear isochronous at each >> client individually. >> >> For an example of how difficult this problem is, try to watch a >> streamed TV show with someone who is 3K miles away, while you have a >> voice channel open so that you can comment on the show to each other >> in real time. SL or not this takes some insight and discipline to >> achieve a "just like being there" experience for even for a party of >> two! This is even true if the content being viewed is already >> local to both participants! For a more typical example: try >> listening to the same radio stream with a friend and try singing >> along to it! >> >> ~HS~ >> >> >> >> On Nov 10, 2009, at 12:41 PM, Carlo Wood wrote: >> >>> On Tue, Nov 10, 2009 at 09:11:57PM +0100, Carlo Wood wrote: >>>> make animated hugs (or any couple animations) really work (with >>>> effort). >>> >>> without* >>> >>> >>> Here is an idea of how it could work: >>> >>> * Viewer A (or object) initiates Multi-gesture Request >>> to N (other) viewers, this involves a list of the >>> animations (UUID) to play for each of the avatars >>> involved, and sounds to play etc, and the starting >>> position in the world of each avatar. >>> * Each viewer reacts with: Ok, will try; or Nope, I won't. >>> If any viewer denies the request (or times out?) >>> then the server informs all viewers that the multi- >>> animation was aborted (and why). [ An optional flag >>> could be to continue anyway, but without the avatar(s) >>> that don't want to. ] >>> * Once all avatars that want to play the multi-animation >>> are known, the server sends them a message: "We have a go!" >>> * All viewers that have all the needed information to >>> continue (downloaded and cached the animations, sounds etc) >>> send a message to the server: "ready!" >>> * As soon as all viewers are ready (optionally, a parameter >>> of the original request includes a timeout after which >>> the delayed avatar is considered to have said "no"), >>> the server informs all viewers to start playing the >>> multi-gesture. >>> >>> And YAY! finally a completely synchronized couple (and >>> multi) animation, even synced with sound! >>> >>> Options in case of delays (timeouts) should be: >>> - Play as soon data available locally, >>> - Wait till at least N, or at least those, avatars >>> are ready. >>> - Abort completely if any can't play in time. >>> - If someone is delayed and the rest already plays >>> the animation, then the viewer can decide to abort >>> or play the animations locally anyway, as soon as >>> they become avaiable, etc etc... All those possibilities >>> are mere bits in already existing messages, so why not. >>> >>> As a side effect of this it should be possible to >>> play a gesture involving animation and sound by ONE >>> avatar (as are the gestures in SL now) but *synchronized*: >>> everyone sees it at the same time, and the animations ARE >>> synced with the sound once the start to play (unlike now, >>> where the animation is played and 30 seconds later you >>> hear the sound). >>> >>> -- >>> Carlo Wood >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >> > > -- > Carlo Wood On Fri, Dec 04, 2009 at 10:19:09AM -0800, Han Sontse wrote: > To clarify my position: > > Key difference is that there really is no good reason for a client > on a fast link to wait > for the client on the slowest link before playing isochronous > content locally. Ever! Um, not to you - but there is for me, and probably others. No reason to dictate what is possible and what is not possible. In my proposal it is possible to NOT wait and just play the animation whenever you have the needed data AND it is possible to wait until all or some clients have it too. Not all, not forever, but configurable. Configurable is always better. For example, if I'm dancing some romantic slow dance then I DO want to be full synchronized with my partner, so that right at the moment I lift him/her up I can type something that refer to lifting him/her up. I'd care less about some noob with a slow link at the other edge of the dance floor - so I'd configure my client to wait for my partner, and wait at most 4 seconds for everyone else, and then start it. > In 'live' performance situations there might be a need to > send trigger events for sequences. (Trigger_sequence) > However, there is no > really good reason I can see to hold up the show because > some clients are on slow links. > > Having clients signal readiness might be a useful *advisory*, > to indicate to a program director that enough clients are fully > cached to start a performance. Well, clearly every viewer by itself is free to do what they want - so it's automatically advisory in nature. > This could be a simple broadcast to all clients requesting caching > status > on a *particular* bundle of pre-cacheable content. No automatic > behavior, optional or > otherwise, is needed for feedback. A scripted object might make > such a broadcast and > simply report each responder's findings to the program director. > > No client to client synchronization is needed > for isochronous content. This is the key point I am making. > There's no reason for the complexity you described: >>>> * As soon as all viewers are ready (optionally, a parameter >>>> of the original request includes a timeout after which >>>> the delayed avatar is considered to have said "no"), >>>> the server informs all viewers to start playing the >>>> multi-gesture. Yes there is (although it's not complex imho). The argument "we can do it simpler, there is no need for this complexity" is exactly the reason that currently all couple animations and all gestures with sound totally suck. If you "simplify" the proposed protocol you take away possibilities, things will not be possible anymore, things that some people might want or need. For example, someone wants to jump in the air shouting "Whoooohoooo!" and right after that run for the door and bolt out. Then that person NEEDS to know when everyone is ready, so that they ALL see the jump and whoohoo at the same time, otherwise some would see him run to the door and jump when already being outside (or worse, zap back inside, jump and then zap outside again). I know I'm not diplomatic, but you'll have to admit that in some cases and/or for some people there IS a need to wait till the slower ones have the data too. -- Carlo Wood --Apple-Mail-1-351513162 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

My apologies to all for = this screwed up thread. I didn't include the mail-host in the = thread for the first part of this = dialog.

On Dec 4, 2009, at 12:42 PM, Carlo = Wood wrote:

I know I'm not diplomatic, but = you'll have to admit
that in some cases and/or for some people there = IS a
need to wait till the slower ones have the data = too.

With all due respect, = Carlo, I am finding that I disagree with your = analysis.

I have a lot of = practical experience in SL getting animations

as well as sound = and textures to synchronize under a lot

of different = conditions by taking into account the client's = existing

cacheing behavior. I'm drawing on that = experience for my assertions.

I can't think of = a single reasonable use case that would *require* clients

to = hold for the slowest link. The examples you have = suggested

don't require it to achieve the outcome you = desire.

The only reason that synchronization is a = problem today in SL is because

there is no provision for = properly notifying the client that two or more

isochronous = assets are to be played as part of a = sequence.

Signaling the client that some = arbitrary bundle of resources are

required to be cached as a = suite will handle a vast majority of

the synchronization = issues, and a MIDI-like sequence handler can manage

the = remainder of specialized cases where complex/strict client side = isochronous

behavior is = desirable.

The outlying cases (the = unreasonable ones) are those that really are beyond the scope = of

what is possible because communication over any appreciable = distances (> 100km ) is unlikely to

ever be instantaneous = in our life times. While wave fronts in electric media do = travel

near the speed of light, the switching fabric relaying = and repeating those signals is

several orders of magnitude = slower even under the ideal cases. Inter-client isochronicity to = the level

a performing musician might desire is simply out of = reach, since the ear-brain interface

is sensitive to latencies = as small as 2 to 5 ms, and acceptable performance almost = completely

breaks down at about >50 ms. =

So here I'll walk through an = example... the hug:

To synchronize a hug all = that is needed is for the

hug object to report that it = contains bundled isochronous

assets during the normal = process of the client caching the

surrounding area. This = bundled sequence might include animation for

the hugger = and the huggee, and maybe a sound or two. It = include

possibly a client side script to move the = target agents into the

correct relative locations to = participate in the hug.

a) In the = simple case the caching of bundled resources has

occurred. =

b) A permissions request would = be sent to the huggee.

c) The = permissions are granted. (were permission not = granted

a subsequent trigger event would be rejected by the = SIM)

d) The hugger's hug object issues a = trigger event which is relayed through

the Sim = to all clients within audio/visual range. =

e) Each = client on receiving the event applies the event to the = indicated

agents using the sequence bundle cached = locally

f) each client views the sequence = isochronously as directed by the

sequence bundle. Timing = for the sequence is local to each client.

Each = client views the hug as a seamless sequence. Though the = exact

starting time of the event is different for each client. = In all but the most

extreme cases of lag, a user = viewing the rendered event will have the perception that

the event = occurred simultaneously for all witnessing/participating = agents.

Ok now for a more complex case where = one or more clients have not cached the

bundle before the = event is triggered:

a) = permission request is granted.

b) = The hugger's hug object issues a trigger event which is relayed = through
= the Sim to all clients within audio/visual = range.

c) As each = client receives the trigger event it may find that it = must

assets are = requested.

d) The sequence is played as soon as = all the assets in the bundle are = queued.

e) Each client views the event as a = seamless sequence. In this case the delay is likely = to

the end = user has no idea when the event was actually sent. Users on = extremely slow links

may wish to have their client = reject events that have become too stale, but this loss for one = client has no

impact on any other client = witnessing the event.

To avoid = e) in the second example it might be desirable for a client to request = sequence bundles

right after caching agent appearances, = to avoid experiencing excessively stale sequence = triggers.

~HS~

---------------

To clarify my position:

Key difference is = that there really is no good reason for a client on a fast link to = wait
for the client on the slowest link before playing isochronous = content locally. Ever!

In 'live' performance situations = there might be a need to
send trigger events for sequences. = (Trigger_sequence<UUID>) However, there is no
really good = reason I can see to hold up the show because
some clients are on slow = links.

Having clients signal readiness might be a useful = *advisory*,
to indicate to a program director that enough clients are = fully cached to start a performance.
This could be a simple broadcast = to all clients requesting caching status
on a *particular* bundle of = pre-cacheable content. No automatic behavior, optional = or
otherwise, is needed for feedback. A scripted object might = make such a broadcast and
simply report each responder's findings to = the program director.

No client to client synchronization is = needed
for isochronous content. This is the key point I = am making.
There's no reason for the complexity you = described:

* As soon as all viewers are = ready (optionally, a = parameter

of the = original request includes a timeout after = which

the = delayed avatar is considered to have said = "no"),

the = server informs all viewers to start playing = the

multi-gesture.

~HS~

On Dec 4, 2009, at 9:42 AM, Carlo Wood = wrote:

Bottomline is, there should be = an option (preferably the default

in the future) to wait a while until all needed assets = are

downloaded, and then there = needds to be a way to tell the other

clients (through the sim) that you are = ready.

I don't seem = much difference there with your ideas :)

Once all assets = are ready (locally cached) then just playing

them in order as described by the gesture info will = work

good enough: there is = only one synchronization point needed:

when to START.

On Fri, Dec 04, = 2009 at 09:01:51AM -0800, Han Sontse wrote:

I've been giving this a lot of = thought recently. It seems to = me

that strict isochronous behavior between clients is not = really

needed for gestures and synchronous animations (dances and = hugs).

It doesn't really matter how = long it takes a client to acquire = the

assets needed for a given interaction. Each client = is showing a

arbitrarily delayed rendition of = the sim state anyway.

It seems more useful to me to = have a mechanism that describes = a

isochronous sequence using arbitrary collection of = animated content;

Audio, MIDI, animation, etc. = A sequence time-line, if you = will.

The sequence lists the assets that will be played in the = time line.

These are then requested/located = as needed by the client. Once = all

are queued, the sequence is played. =46rom = each client's perspective

the script plays in local real = time, but without any = synchronization

between clients. = Tighter synchronization between clients could = be

achieved simply by having a mechanism for clients to = be notified

that sequenced objects are = present in the local environment. = The

client can then choose to = pre-cache these sequences subject to = user

preference.

As the gesture mechanism = operates today in SL, some content = will

begin playing as expected, while other content declared in = the

sequence are still loading. I do not know if this is = as designed,

or it reflects some collection = of bugs in the gesture handling

process.

What is missing here is a robust = method for notifying clients = that

isochronous groupings of content are present in the = local

environment.

A more complex issue exists for = situations where multiple = clients

seek to create a live interactive performance. The = current state of

the internet as a whole simply = cannot support hard isochronous

behavior. = However a performing group at a physical location = might

cause a library of sequences to be cached in the clients, = which can

then be triggered by a tokenized = sequence embedded in a = QuickTime

Stream. This choreography = would then appear isochronous at = each

client = individually.

For an example of how difficult = this problem is, try to watch a

streamed TV show with someone = who is 3K miles away, while you have = a

voice channel open so that you can comment on the show to = each other

in real time. SL or not = this takes some insight and discipline = to

achieve a "just like being there" experience for even for = a party of

two! This is even = true if the content being viewed is = already

local to both participants! For a more = typical example: try

listening to the same radio = stream with a friend and try = singing

along to it!

~HS~

On Nov 10, 2009, at 12:41 PM, = Carlo Wood wrote:

On = Tue, Nov 10, 2009 at 09:11:57PM +0100, Carlo Wood = wrote:

make animated hugs (or any = couple animations) really work = (with

effort).

without*

Here = is an idea of how it could = work:

* = Viewer A (or object) initiates Multi-gesture = Request

to N = (other) viewers, this involves a list of = the

animations (UUID) to play for each of the = avatars

involved, and sounds to play etc, and the = starting

position= in the world of each = avatar.

* Each = viewer reacts with: Ok, will try; or Nope, I = won't.

If any = viewer denies the request (or times = out?)

then = the server informs all viewers that the = multi-

animation was aborted (and why). [ An optional = flag

could = be to continue anyway, but without the = avatar(s)

that = don't want to. ]

* Once = all avatars that want to play the = multi-animation

are = known, the server sends them a message: "We have a = go!"

* All = viewers that have all the needed information = to

continue= (downloaded and cached the animations, sounds = etc)

send a = message to the server: = "ready!"

* As = soon as all viewers are ready (optionally, a = parameter

of the = original request includes a timeout after = which

the = delayed avatar is considered to have said = "no"),

the = server informs all viewers to start playing = the

multi-gesture.

And = YAY! finally a completely synchronized couple = (and

multi) = animation, even synced with = sound!

Options = in case of delays (timeouts) should = be:

- Play = as soon data available = locally,

- Wait = till at least N, or at least those, = avatars

are = ready.

- = Abort completely if any can't play in = time.

- If = someone is delayed and the rest already = plays

the = animation, then the viewer can decide to = abort

or = play the animations locally anyway, as soon = as

they = become avaiable, etc etc... All those = possibilities

are = mere bits in already existing messages, so why = not.

As a = side effect of this it should be possible = to

play a = gesture involving animation and sound by = ONE

avatar = (as are the gestures in SL now) but = *synchronized*:

everyone= sees it at the same time, and the animations = ARE

synced = with the sound once the start to play (unlike = now,

where = the animation is played and 30 seconds later = you

hear = the sound).

--

Carlo= Wood <carlo@alinoe.com>
=

_______________________________________________
ogpx mailing = list
ogpx@ietf.org
https://www.ietf.org/m= ailman/listinfo/ogpx

--
Carlo = Wood <carlo@alinoe.com>
=

On Fri, Dec 04, 2009 at 10:19:09AM -0800, = Han Sontse wrote:

To clarify my = position:

Key difference = is that there really is no good reason for a = client

on a fast link to = wait

for the client on the = slowest link before playing isochronous

content locally. Ever!

Um, not = to you - but there is for me, and probably others.
No reason to = dictate what is possible and what is not possible.

In my proposal = it is possible to NOT wait and just play the
animation whenever you = have the needed data AND it is possible
to wait until all or some = clients have it too. Not all, not
forever, but configurable. = Configurable is always better.

For example, if I'm dancing some = romantic slow dance
then I DO want to be full synchronized with my = partner,
so that right at the moment I lift him/her up I can = type
something that refer to lifting him/her up.

I'd care less = about some noob with a slow link at the
other edge of the dance floor = - so I'd configure my
client to wait for my partner, and wait at most = 4 seconds
for everyone else, and then start it.

In 'live' performance situations there might be a need = to

send trigger events for = sequences. = (Trigger_sequence<UUID>)

However, there is no

really good reason I can see to hold up the show = because

some clients are on = slow links.

Having clients = signal readiness might be a useful = *advisory*,

to indicate to a = program director that enough clients are = fully

cached to start a = performance.

Well, clearly every viewer by itself is = free to do what
they want - so it's automatically advisory in = nature.

This could be a simple = broadcast to all clients requesting caching

status

on a = *particular* bundle of pre-cacheable content. No = automatic

behavior, optional = or

otherwise, is needed for = feedback. A scripted object might make

such a broadcast and

simply report each responder's findings to the program = director.

No client to = client synchronization is needed

for isochronous content. This is the key point = I am making.

There's no reason = for the complexity you described:

* As soon as all viewers are = ready (optionally, a = parameter

of the original request includes = a timeout after = which

the delayed avatar is considered = to have said = "no"),

the server informs all viewers = to start playing = the

multi-gesture.

Yes there is (although it's not complex imho).
The = argument "we can do it simpler, there is no need for
this complexity" = is exactly the reason that currently
all couple animations and all = gestures with sound totally
suck.

If you "simplify" the = proposed protocol you take away
possibilities, things will not be = possible anymore,
things that some people might want or = need.

For example, someone wants to jump in the air
shouting = "Whoooohoooo!" and right after that run
for the door and bolt = out.

Then that person NEEDS to know when everyone is ready,
so = that they ALL see the jump and whoohoo at the same
time, otherwise = some would see him run to the door
and jump when already being = outside (or worse, zap
back inside, jump and then zap outside = again).

I know I'm not diplomatic, but you'll have to = admit
that in some cases and/or for some people there IS a
need to = wait till the slower ones have the data too.

--
Carlo = Wood <carlo@alinoe.com>

= --Apple-Mail-1-351513162-- From carlo@alinoe.com Sat Dec 5 04:43:58 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB86E3A67FB for ; Sat, 5 Dec 2009 04:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MstExNUG6xXB for ; Sat, 5 Dec 2009 04:43:58 -0800 (PST) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 930593A683E for ; Sat, 5 Dec 2009 04:43:57 -0800 (PST) Received: from edge03.upc.biz ([192.168.13.238]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091205124347.RADP27596.viefep16-int.chello.at@edge03.upc.biz>; Sat, 5 Dec 2009 13:43:47 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id DQjk1d0Cz0FlQed03QjmZZ; Sat, 05 Dec 2009 13:43:47 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NGtwS-0002m5-Ai; Sat, 05 Dec 2009 13:40:52 +0100 Date: Sat, 5 Dec 2009 13:40:52 +0100 From: Carlo Wood To: Han Sontse Message-ID: <20091205124052.GA9193@alinoe.com> References: <4AF8ECDE.2010900@cox.net> <20091110201157.GA10861@alinoe.com> <20091110204155.GA5757@alinoe.com> <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] Synchronization of gestures (was: Limits to interoperability of scripted objects) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 12:43:59 -0000 On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: > With all due respect, Carlo, I am finding that I disagree with your analysis. There is no analysis.. it is something has been said before on the list: if YOU don't want something, then that doesn't mean there will be no need for it in the future by others. You shouldn't take YOUR experience and desires and then say: "we will never need this, NOBODY will EVER need this", while it's relatively easy and simple to add the *support* for it to the protocol! By adding the *possibility* for viewers to wait for others, you do not force anyone to do it different from what you describe. But you also don't take away the possibility to do it how other people WANT it (like me, I personally think this is important - so thus far we have a 50% - 50% vote for the NEED of this wait feature). So, to be really undiplomatic blunt: who are you to deny me this experience? While adding just a little to the protocol we BOTH can be happy? You can do it your way, and I can do it my way? But you say: "You don't need it" and want to remove the possibility from the protocol so that you can do it your way and I CANNOT do it the way I want ?! THAT is the reasoning behind NOT leaving out rather trivial options to the protocol. And really, this has been said on the list before a few times imho (and no, I'm not going to find that back). > I have a lot of practical experience in SL getting animations > as well as sound and textures to synchronize under a lot > of different conditions by taking into account the client's existing > cacheing behavior. I'm drawing on that experience for my assertions. I am too, and I say I need this. > I can't think of a single reasonable use case that would *require* clients > to hold for the slowest link. The examples you have suggested I can. > don't require it to achieve the outcome you desire. ??? Then you didn't read very well what I said. If you want to do what I said then you *NEED* the possibility to wait for other (some) clients (some limited time), and why not, have the possibility to abort, or continue anyway (as you want). Having those options you can synchronize the experience well within lag-time, well within typing-delay time (ie, under 1 second). If you don't wait, the playing time could run up till 30 seconds or more! Having those options you can synchronize the experience well within 1 second AND you can do what you want: just state don't wait for anyone and play stuff the second you get it. [...] > So here I'll walk through an example... the hug: > > To synchronize a hug all that is needed is for the "all that is needed" to accomplish YOUR needs and views. For me, I realllllly need to know when other clients are ready too. [...snip...] > be longer for some clients than others. The exact wall clock delay does not > matter since the end user has no idea when the event was actually sent. Yes we totally disagree here, and you are wrong: there are many other shared experiences (typed text, and remaining movement of the avatar before and after; not to mention voice chat) that need to be more or less in sync with gestures; the user WILL have an idea when the event was sent. The wall clock DOES matter - certainly when the delay can run up to a whole minute. You are "right" for delays less than a second, and I argue that we should try hard to get the shared experience synchronized within one second IF THE USER(S) SO DESIRE. I already gave you examples where it is notable when the delay is larger, but I guess every example is personal. If YOU don't care that your friends see you bolt for the door and once outside you jump and shout "Whooohooo!", while you really intended to first jump and shout and THEN run for the door, then well-- that is entirely your choice. Now let me, and others, have mine. Another example, your hug: You initiate a hug request (your client already has the needed assets or starts to download them immediately). By the time that your partner clicks 'Ok', your viewer is ready and immediately starts to play the hug. While hugging you say: "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees that text while they don't see you hugging yet; others do however. Because others DO, we NEED support in the protocol to know when other clients are ready (at least, have all the needed data cached; any other delay is too short to be bothered with-- I'm with you on that then). -- Carlo Wood From carlo@alinoe.com Sat Dec 5 04:51:51 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244B03A67E3 for ; Sat, 5 Dec 2009 04:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAtV1aY+Y36s for ; Sat, 5 Dec 2009 04:51:50 -0800 (PST) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 0E38A3A67FB for ; Sat, 5 Dec 2009 04:51:49 -0800 (PST) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091205125137.VQXM21592.viefep11-int.chello.at@edge04.upc.biz>; Sat, 5 Dec 2009 13:51:37 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id DQrb1d0Bq0FlQed04QrcHH; Sat, 05 Dec 2009 13:51:37 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NGu42-0002rG-VS; Sat, 05 Dec 2009 13:48:43 +0100 Date: Sat, 5 Dec 2009 13:48:42 +0100 From: Carlo Wood To: Han Sontse Message-ID: <20091205124842.GB9193@alinoe.com> References: <4AF8ECDE.2010900@cox.net> <20091110201157.GA10861@alinoe.com> <20091110204155.GA5757@alinoe.com> <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> <20091205124052.GA9193@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091205124052.GA9193@alinoe.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] Synchronization of gestures (was: Limits to interoperability of scripted objects) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 12:51:51 -0000 Blah! Before, this was a private conversation... I didn't notice that Han suddenly CC-ed this list (quoting my private mail in the process, thank you very much), so this post is really private. Had I known it was now suddenly public, I would never have "attacked" Han in an almost personal way, of course. I would appologise but well, I'm not the one that suddenly started to CC the ogpx list :/ Anyway, I guess I'll check the CC line better next time I react to private mail, I guess. Carlo -- Carlo Wood From lenglish5@cox.net Sat Dec 5 06:00:38 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705CB3A6803 for ; Sat, 5 Dec 2009 06:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J2rWAJu79G1 for ; Sat, 5 Dec 2009 06:00:37 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id 55CEB3A6909 for ; Sat, 5 Dec 2009 06:00:37 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao105.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091205140028.IZJK12229.fed1rmmtao105.cox.net@fed1rmimpo03.cox.net>; Sat, 5 Dec 2009 09:00:28 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id DS0T1d00F2l1Ksg04S0U5X; Sat, 05 Dec 2009 09:00:28 -0500 X-VR-Score: -200.00 X-Authority-Analysis: v=1.1 cv=+jAW79NKwrNAYaynTXPjtTngPQL9M8sBtdBfwSVg0dQ= c=1 sm=1 a=Wajolswj7cQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=cfHPFXhNAAAA:8 a=vqU45PQxtpwfcgCrAGMA:9 a=GUNWgEP1OiaEXe2RgtwA:7 a=Wdx-Of61uvUYMSSJlvqhuPbbmzgA:4 a=Ni0cLNo2ObQeIrpY:21 a=YjWBTgekACIhhnA8:21 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4B1A677B.4090204@cox.net> Date: Sat, 05 Dec 2009 07:00:27 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Carlo Wood References: <4AF8ECDE.2010900@cox.net> <20091110201157.GA10861@alinoe.com> <20091110204155.GA5757@alinoe.com> <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> <20091205124052.GA9193@alinoe.com> In-Reply-To: <20091205124052.GA9193@alinoe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] Synchronization of gestures X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 14:00:38 -0000 All this goes back to what I just posted on the SLDEV list about taking initiative and coding something up. Having the ability for clients to talk to each other rather than some 3rd party service might blur the line concerning what VWRAP is supposed to be talking about, but, IMHO, the line is getting blurred anyway. What's the difference between a plugin sitting on someone's desktop in order to augment the client in some way, and a plugin that actually allows clients to talk to each other directly in order to collectively augment them in some way? As far as I'm concerned, these discussions about clients talking to each other are just extensions totalks about what responsibilities client plugins might have. My current project is based on this idea: http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin I'm writing a SL client- squeak bridge (starting off easy with a port of my do-nothing Python client for practice) that will allow me to test new client plugin ideas. The Holy Grail for the project will be to integrate Cobalt/Croquet with SL in some way(s) and that is just the tip of an iceberg that is being held under water by a large outcropping of land. There's more potential in P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR VWRAP (clear-cut client-server worlds) taken separately. While VWRAP/OGP/whatever's charter may not consider the P2P approach as relevant, the fact is, P2P is potentially in ANY extension of services involving clients which aren't talking exclusively to an old school SL simulator. Lawson Carlo Wood wrote: > On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: > >> With all due respect, Carlo, I am finding that I disagree with your analysis. >> > > There is no analysis.. it is something has been said before > on the list: if YOU don't want something, then that doesn't > mean there will be no need for it in the future by others. > > You shouldn't take YOUR experience and desires and then say: > "we will never need this, NOBODY will EVER need this", > while it's relatively easy and simple to add the *support* > for it to the protocol! > > By adding the *possibility* for viewers to wait for others, > you do not force anyone to do it different from what you > describe. But you also don't take away the possibility to > do it how other people WANT it (like me, I personally think > this is important - so thus far we have a 50% - 50% vote for > the NEED of this wait feature). > > So, to be really undiplomatic blunt: who are you to deny > me this experience? While adding just a little to the protocol > we BOTH can be happy? You can do it your way, and I can do it > my way? But you say: "You don't need it" and want to remove > the possibility from the protocol so that you can do it your > way and I CANNOT do it the way I want ?! > > THAT is the reasoning behind NOT leaving out rather trivial > options to the protocol. And really, this has been said on > the list before a few times imho (and no, I'm not going to > find that back). > > >> I have a lot of practical experience in SL getting animations >> as well as sound and textures to synchronize under a lot >> of different conditions by taking into account the client's existing >> cacheing behavior. I'm drawing on that experience for my assertions. >> > > I am too, and I say I need this. > > >> I can't think of a single reasonable use case that would *require* clients >> to hold for the slowest link. The examples you have suggested >> > > I can. > > >> don't require it to achieve the outcome you desire. >> > > ??? Then you didn't read very well what I said. > If you want to do what I said then you *NEED* the possibility to wait > for other (some) clients (some limited time), and why not, have the > possibility to abort, or continue anyway (as you want). > > Having those options you can synchronize the experience well within > lag-time, well within typing-delay time (ie, under 1 second). If you > don't wait, the playing time could run up till 30 seconds or more! > > Having those options you can synchronize the experience well within > 1 second AND you can do what you want: just state don't wait for anyone > and play stuff the second you get it. > > [...] > >> So here I'll walk through an example... the hug: >> >> To synchronize a hug all that is needed is for the >> > > "all that is needed" to accomplish YOUR needs and views. > For me, I realllllly need to know when other clients are > ready too. > > [...snip...] > >> be longer for some clients than others. The exact wall clock delay does not >> matter since the end user has no idea when the event was actually sent. >> > > Yes we totally disagree here, and you are wrong: there are many other > shared experiences (typed text, and remaining movement of the avatar > before and after; not to mention voice chat) that need to be more or > less in sync with gestures; the user WILL have an idea when the event > was sent. > > The wall clock DOES matter - certainly when the delay can run > up to a whole minute. > > You are "right" for delays less than a second, and I argue > that we should try hard to get the shared experience synchronized > within one second IF THE USER(S) SO DESIRE. > > I already gave you examples where it is notable when the delay > is larger, but I guess every example is personal. If YOU don't > care that your friends see you bolt for the door and once outside > you jump and shout "Whooohooo!", while you really intended to > first jump and shout and THEN run for the door, then well-- > that is entirely your choice. Now let me, and others, have mine. > > Another example, your hug: You initiate a hug request (your client > already has the needed assets or starts to download them immediately). > By the time that your partner clicks 'Ok', your viewer is ready > and immediately starts to play the hug. While hugging you say: > "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees > that text while they don't see you hugging yet; others do however. > Because others DO, we NEED support in the protocol to know when > other clients are ready (at least, have all the needed data > cached; any other delay is too short to be bothered with-- I'm > with you on that then). > > From morgaine.dinova@googlemail.com Sat Dec 5 10:15:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274783A68BE for ; Sat, 5 Dec 2009 10:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzM4ba7obOCI for ; Sat, 5 Dec 2009 10:15:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 6380D3A6896 for ; Sat, 5 Dec 2009 10:15:06 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so125106eyd.51 for ; Sat, 05 Dec 2009 10:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=QQdyJ4PXHxXIagGljW9on+VhXipk0wWc47BYz7qKmEM=; b=GSd1AnPPc19nhZ62v7hCcOj+xMfQHFrKgWXYguiNq7fWDfb+cFYVHscBozcAk9TPF2 V6v9Newv0P9PNOi4CHAgDChaC+mW0VJKoO8ZLbpQ6BNRYmEI9vop/uGuj8DhnmTYaY7j VHMf+eFsam8VuenS7Na+T5hwrUMt28Vv4uaxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h1JswRwHT1hsJyPOkrewUBgay/Ytmq0E12QtAOn96zkfHOph7TDwUf30eGS4xJF+V+ lZG/6cT63gvK/sIQrDUB+gGfUvu8VhBm0E47S6aXbWFCXp1as3r3ImvKfWCjT6Jlwjtv V50s++RAM1qPONOO93LV9NX65320Bw0RzKKW8= MIME-Version: 1.0 Received: by 10.216.86.135 with SMTP id w7mr1619231wee.176.1260036893991; Sat, 05 Dec 2009 10:14:53 -0800 (PST) Date: Sat, 5 Dec 2009 18:14:53 +0000 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6d6495678623e0479ff33f9 Subject: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 18:15:10 -0000 --0016e6d6495678623e0479ff33f9 Content-Type: text/plain; charset=ISO-8859-1 I agree with Lawson, but the topic goes far beyond gestures, so this is a new thread. Putting it another way, the days of the monolithic client are over, in the same way as the days of the walled garden and single service provider are over. In VWRAP, we are formalizing the unbundling of service provision so that server-side is becoming distributed, but we don't seem to have grasped the corresponding concept of non-monolithic clients yet. Perhaps the client needs more flexibility than we are currently considering. Although we are not dealing with client application architecture here, we * are* dealing with protocol endpoint architecture, and the design of clients has a direct impact on that. The protocol should not require nor give preference to any one particular client architecture, in the same way as we seek not to hardwire any single choice of server-side deployment pattern. It seems reasonable to apply this same philosophy to the client endpoint, so that the protocol can allow for many different kinds of client-side deployment. Midway through the two years of operation of the Architecture Working Group in SL, we explored a variety of client-side scenarios, including this design for a multi-process client. This split out all functional parts of a client into separate processes, all interconnected through a "Mediator" hub process via sockets, while also accepting point-to-point and shared-memory communication paths as accelerators between subprocesses where required for speed. Such a client architecture is a perfect match for this new age of multicore, among a huge list of other benefits enumerated on that page. It can be considered the fully distributed end of the large spectrum of possible clients. Lawson's SL client- Squeak bridge represents another split, libomv's gridproxy and its Jabber pluginshows another, while LL's own system for media plugins is yet another. All these moves take us away from the notion of a VW client being a monolithic entity, and correspondingly, we should no longer assume that the client-side protocol endpoint is monolithic either. To that end, it might be an effective approach to model VWRAP as a *protocol over sets of sources and sinks for data*. One set is server-side, which we are already modelling as a multiplicity of service endpoints, and another set is client-side, representing the many subsystems that deal with different aspects of interacting with VW worlds and talking to their services. Those subsystems are clear candidates for distinct protocol endpoints of their own. Such a model would more accurately reflect how client applications are actually built (in other words, in a modular fashion), instead of funneling everything through a single client-side endpoint. The current single-client-endpoint approach is hardwiring an unnecessary bottleneck into the client model, as well as encouraging a poor design for clients through making all data appear at a single doorway. Perhaps we need to reflect on this a little before rushing ahead with yesterday's design philosophy for protocol endpoints. Morgaine. ================================= On Sat, Dec 5, 2009 at 2:00 PM, Lawson English wrote: > All this goes back to what I just posted on the SLDEV list about taking > initiative and coding something up. Having the ability for clients to talk > to each other rather than some 3rd party service might blur the line > concerning what VWRAP is supposed to be talking about, but, IMHO, the line > is getting blurred anyway. > > What's the difference between a plugin sitting on someone's desktop in > order to augment the client in some way, and a plugin that actually allows > clients to talk to each other directly in order to collectively augment them > in some way? As far as I'm concerned, these discussions about clients > talking to each other are just extensions totalks about what > responsibilities client plugins might have. > > My current project is based on this idea: > > > http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin > > I'm writing a SL client- squeak bridge (starting off easy with a port of my > do-nothing Python client for practice) that will allow me to test new > client plugin ideas. The Holy Grail for the project will be to integrate > Cobalt/Croquet with SL in some way(s) and that is just the tip of an iceberg > that is being held under water by a large outcropping of land. There's more > potential in P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR > VWRAP (clear-cut client-server worlds) taken separately. While > VWRAP/OGP/whatever's charter may not consider the P2P approach as relevant, > the fact is, P2P is potentially in ANY extension of services involving > clients which aren't talking exclusively to an old school SL simulator. > > > Lawson > > > > > Carlo Wood wrote: > >> On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: >> >> >>> With all due respect, Carlo, I am finding that I disagree with your >>> analysis. >>> >>> >> >> There is no analysis.. it is something has been said before >> on the list: if YOU don't want something, then that doesn't >> mean there will be no need for it in the future by others. >> >> You shouldn't take YOUR experience and desires and then say: >> "we will never need this, NOBODY will EVER need this", >> while it's relatively easy and simple to add the *support* >> for it to the protocol! >> >> By adding the *possibility* for viewers to wait for others, >> you do not force anyone to do it different from what you >> describe. But you also don't take away the possibility to >> do it how other people WANT it (like me, I personally think >> this is important - so thus far we have a 50% - 50% vote for >> the NEED of this wait feature). >> >> So, to be really undiplomatic blunt: who are you to deny >> me this experience? While adding just a little to the protocol >> we BOTH can be happy? You can do it your way, and I can do it >> my way? But you say: "You don't need it" and want to remove >> the possibility from the protocol so that you can do it your >> way and I CANNOT do it the way I want ?! >> >> THAT is the reasoning behind NOT leaving out rather trivial >> options to the protocol. And really, this has been said on >> the list before a few times imho (and no, I'm not going to >> find that back). >> >> >> >>> I have a lot of practical experience in SL getting animations >>> as well as sound and textures to synchronize under a lot >>> of different conditions by taking into account the client's existing >>> cacheing behavior. I'm drawing on that experience for my assertions. >>> >>> >> >> I am too, and I say I need this. >> >> >> >>> I can't think of a single reasonable use case that would *require* >>> clients >>> to hold for the slowest link. The examples you have suggested >>> >>> >> >> I can. >> >> >> >>> don't require it to achieve the outcome you desire. >>> >> >> ??? Then you didn't read very well what I said. >> If you want to do what I said then you *NEED* the possibility to wait >> for other (some) clients (some limited time), and why not, have the >> possibility to abort, or continue anyway (as you want). >> >> Having those options you can synchronize the experience well within >> lag-time, well within typing-delay time (ie, under 1 second). If you >> don't wait, the playing time could run up till 30 seconds or more! >> >> Having those options you can synchronize the experience well within >> 1 second AND you can do what you want: just state don't wait for anyone >> and play stuff the second you get it. >> >> [...] >> >> >>> So here I'll walk through an example... the hug: >>> >>> To synchronize a hug all that is needed is for the >>> >> >> "all that is needed" to accomplish YOUR needs and views. >> For me, I realllllly need to know when other clients are >> ready too. >> >> [...snip...] >> >> >>> be longer for some clients than others. The exact wall clock delay does >>> not >>> matter since the end user has no idea when the event was actually sent. >>> >>> >> >> Yes we totally disagree here, and you are wrong: there are many other >> shared experiences (typed text, and remaining movement of the avatar >> before and after; not to mention voice chat) that need to be more or >> less in sync with gestures; the user WILL have an idea when the event >> was sent. >> >> The wall clock DOES matter - certainly when the delay can run >> up to a whole minute. >> >> You are "right" for delays less than a second, and I argue >> that we should try hard to get the shared experience synchronized >> within one second IF THE USER(S) SO DESIRE. >> >> I already gave you examples where it is notable when the delay >> is larger, but I guess every example is personal. If YOU don't >> care that your friends see you bolt for the door and once outside >> you jump and shout "Whooohooo!", while you really intended to >> first jump and shout and THEN run for the door, then well-- >> that is entirely your choice. Now let me, and others, have mine. >> >> Another example, your hug: You initiate a hug request (your client >> already has the needed assets or starts to download them immediately). >> By the time that your partner clicks 'Ok', your viewer is ready >> and immediately starts to play the hug. While hugging you say: >> "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees >> that text while they don't see you hugging yet; others do however. >> Because others DO, we NEED support in the protocol to know when >> other clients are ready (at least, have all the needed data >> cached; any other delay is too short to be bothered with-- I'm >> with you on that then). >> >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0016e6d6495678623e0479ff33f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Lawson, but the topic goes far beyond gestures, so this is a n= ew thread.

Putting it another way, the days of the monolithic client= are over, in the same way as the days of the walled garden and single serv= ice provider are over.

In VWRAP, we are formalizing the unbundling of service provision so tha= t server-side is becoming distributed, but we don't seem to have graspe= d the corresponding concept of non-monolithic clients yet.=A0 Perhaps the c= lient needs more flexibility than we are currently considering.

Although we are not dealing with client application architecture here, = we are dealing with protocol endpoint architecture, and the design o= f clients has a direct impact on that.=A0 The protocol should not require n= or give preference to any one particular client architecture, in the same w= ay as we seek not to hardwire any single choice of server-side deployment p= attern.=A0 It seems reasonable to apply this same philosophy to the client = endpoint, so that the protocol can allow for many different kinds of client= -side deployment.

Midway through the two years of operation of the Architecture Working G= roup in SL, we explored a variety of client-side scenarios, including this = design for a multi-process client .=A0 This split out all functiona= l parts of a client into separate processes, all interconnected through a &= quot;Mediator" hub process via sockets, while also accepting point-to-= point and shared-memory communication paths as accelerators between subproc= esses where required for speed.

Such a client architecture is a perfect match for this new age of multi= core, among a huge list of other benefits enumerated on that page.=A0 It ca= n be considered the fully distributed end of the large spectrum of possible= clients.=A0 Lawson's SL client- Squeak bridge represents another split= , libomv's gridpr= oxy and its Jabber plugin shows another, while LL's own system for me= dia plugins is yet another.=A0 All these moves take us away from the notion= of a VW client being a monolithic entity, and correspondingly, we should n= o longer assume that the client-side protocol endpoint is monolithic either= .

To that end, it might be an effective approach to model VWRAP as a p= rotocol over sets of sources and sinks for data.=A0 One set is server-s= ide, which we are already modelling as a multiplicity of service endpoints,= and another set is client-side, representing the many subsystems that deal= with different aspects of interacting with VW worlds and talking to their = services.=A0 Those subsystems are clear candidates for distinct protocol en= dpoints of their own.

Such a model would more accurately reflect how client applications are = actually built (in other words, in a modular fashion), instead of funneling= everything through a single client-side endpoint.=A0 The current single-cl= ient-endpoint approach is hardwiring an unnecessary bottleneck into the cli= ent model, as well as encouraging a poor design for clients through making = all data appear at a single doorway.

Perhaps we need to reflect on this a little before rushing ahead with y= esterday's design philosophy for protocol endpoints.

Morgain= e.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sat, Dec 5, 2009 at 2:00 PM, Lawson English <lenglish5@cox.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> All this goes back to what I just posted on the SLDEV list about taking ini= tiative and coding something up. Having the ability for clients to talk to = each other rather than some 3rd party service might blur the line concernin= g what VWRAP is supposed to be talking about, but, IMHO, the line is gettin= g blurred anyway.

What's the difference between a plugin sitting on someone's desktop= in order to augment the client in some way, and a plugin that actually all= ows clients to talk to each other directly in order to collectively augment= them in some way? As far as I'm concerned, these discussions about cli= ents talking to each other are just extensions totalks about what responsib= ilities client plugins might have.

My current project is based on this idea:

http://wiki.sec= ondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_t= o_Media_Plugin

I'm writing a SL client- squeak bridge (starting off easy with a port o= f my =A0do-nothing Python client for practice) that will allow me to test n= ew client plugin ideas. The Holy Grail for the project will be to integrate= Cobalt/Croquet with SL in some way(s) and that is just the tip of an icebe= rg that is being held under water by a large outcropping of land. There'= ;s more potential in P2P-VWRAP hybrids than there is in =A0P2P (Croquet/Cob= alt) OR VWRAP (clear-cut client-server worlds) taken separately. While VWRA= P/OGP/whatever's charter may not consider the P2P approach as relevant,= the fact is, P2P is potentially in ANY extension of services involving cli= ents which aren't talking exclusively to an old school SL simulator.

Lawson

Carlo Wood wrote:

On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:
=A0

With all due respect, =A0Carlo, I am finding that I disagree with your anal= ysis.
=A0 =A0

There is no analysis.. it is something has been said before
on the list: if YOU don't want something, then that doesn't
mean there will be no need for it in the future by others.

You shouldn't take YOUR experience and desires and then say:
"we will never need this, NOBODY will EVER need this",
while it's relatively easy and simple to add the *support*
for it to the protocol!

By adding the *possibility* for viewers to wait for others,
you do not force anyone to do it different from what you
describe. But you also don't take away the possibility to
do it how other people WANT it (like me, I personally think
this is important - so thus far we have a 50% - 50% vote for
the NEED of this wait feature).

So, to be really undiplomatic blunt: who are you to deny
me this experience? While adding just a little to the protocol
we BOTH can be happy? You can do it your way, and I can do it
my way? But you say: "You don't need it" and want to remove the possibility from the protocol so that you can do it your
way and I CANNOT do it the way I want ?!

THAT is the reasoning behind NOT leaving out rather trivial
options to the protocol. And really, this has been said on
the list before a few times imho (and no, I'm not going to
find that back).

=A0

I have a lot of practical experience in SL getting animations
as well as sound and textures to synchronize under a lot
of different conditions by taking into account the client's existing cacheing behavior. =A0 I'm drawing on that experience for my assertions= .
=A0 =A0

I am too, and I say I need this.

=A0

I can't think of a single reasonable use case that would *require* clie= nts
to hold for the slowest link. =A0The examples you have suggested
=A0 =A0

I can.

=A0

don't require it to achieve the outcome you desire. =A0 =A0

??? Then you didn't read very well what I said.
If you want to do what I said then you *NEED* the possibility to wait
for other (some) clients (some limited time), and why not, have the
possibility to abort, or continue anyway (as you want).

Having those options you can synchronize the experience well within
lag-time, well within typing-delay time (ie, under 1 second). If you
don't wait, the playing time could run up till 30 seconds or more!

Having those options you can synchronize the experience well within
1 second AND you can do what you want: just state don't wait for anyone=
and play stuff the second you get it.

[...]
=A0

So here I'll walk through an example... the hug:

To synchronize a hug all that is needed is for the =A0 =A0

"all that is needed" to accomplish YOUR needs and views.
For me, I realllllly need to know when other clients are
ready too.

[...snip...]
=A0

be longer for some clients than others. =A0The exact wall clock delay does = not
matter since the end user has no idea when the event was actually sent.
=A0 =A0

Yes we totally disagree here, and you are wrong: there are many other
shared experiences (typed text, and remaining movement of the avatar
before and after; not to mention voice chat) that need to be more or
less in sync with gestures; the user WILL have an idea when the event
was sent.

The wall clock DOES matter - certainly when the delay can run
up to a whole minute.

You are "right" for delays less than a second, and I argue
that we should try hard to get the shared experience synchronized
within one second IF THE USER(S) SO DESIRE.

I already gave you examples where it is notable when the delay
is larger, but I guess every example is personal. If YOU don't
care that your friends see you bolt for the door and once outside
you jump and shout "Whooohooo!", while you really intended to
first jump and shout and THEN run for the door, then well--
that is entirely your choice. Now let me, and others, have mine.

Another example, your hug: You initiate a hug request (your client
already has the needed assets or starts to download them immediately).
By the time that your partner clicks 'Ok', your viewer is ready
and immediately starts to play the hug. While hugging you say:
"Mmmmmmmmmmm, so nice". And YOU don't care if your partner se= es
that text while they don't see you hugging yet; others do however.
Because others DO, we NEED support in the protocol to know when
other clients are ready (at least, have all the needed data
cached; any other delay is too short to be bothered with-- I'm
with you on that then).

=A0

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0016e6d6495678623e0479ff33f9-- From lenglish5@cox.net Sun Dec 6 01:24:54 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF9A3A6774 for ; Sun, 6 Dec 2009 01:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_50=0.001, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-qR9+Kkj-hr for ; Sun, 6 Dec 2009 01:24:53 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id E4F6F3A635F for ; Sun, 6 Dec 2009 01:24:52 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091206092442.FWKL26337.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Sun, 6 Dec 2009 04:24:42 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id DlQi1d0072l1Ksg04lQj69; Sun, 06 Dec 2009 04:24:43 -0500 X-VR-Score: -87.00 X-Authority-Analysis: v=1.1 cv=+jAW79NKwrNAYaynTXPjtTngPQL9M8sBtdBfwSVg0dQ= c=1 sm=1 a=0myZBgw-LeIA:10 a=Wajolswj7cQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=cfHPFXhNAAAA:8 a=fMQpIoHGAAAA:8 a=78VZib3qAAAA:8 a=kviXuzpPAAAA:8 a=48vgC7mUAAAA:8 a=KJw-Iy9pthp6okRwSPoA:9 a=7BLYjie9em6375yMELUA:7 a=DfXe9EvVNKcT4s82shZQ2MZYTN0A:4 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=Vu2BV1Ck5eJIiU7Y:21 a=llWXuX5P5wEtmJkI:21 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4B1B785A.9000602@cox.net> Date: Sun, 06 Dec 2009 02:24:42 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 09:24:54 -0000 Thanks Morgaine. The concept of a plugin-driven client is simply your modular client idea built off of the existing LL client. The final extension of your client is a collection of interacting plugins with a central mediator and possibly connections between plugins and/or services that bypass the mediator. So the network looks like a star network of plugins with a central mediator and a conduit of connections between plugins and services. The final design would make the mediator an optional central point to establish new connections, and process scripting/macro/GUI commands, while the actual functions are carried out by the outlying modules, which may not even be on the same computer. Similarly, the "server" side might be equally as distributed and the distinction between client and server disappears completely with clients handling some 3D element generation and physics and assets, etc, while the server broadcasts 2D mashups of the client's perspective to cell phones. Etc. So at one end, we have pure client-server designs like Second Life, at the other extreme, purely p2p worlds like Croquet, and every possible combination/permutation in-between. Lawson Morgaine wrote: > I agree with Lawson, but the topic goes far beyond gestures, so this > is a new thread. > > Putting it another way, the days of the monolithic client are over, in > the same way as the days of the walled garden and single service > provider are over. > > In VWRAP, we are formalizing the unbundling of service provision so > that server-side is becoming distributed, but we don't seem to have > grasped the corresponding concept of non-monolithic clients yet. > Perhaps the client needs more flexibility than we are currently > considering. > > Although we are not dealing with client application architecture here, > we /are/ dealing with protocol endpoint architecture, and the design > of clients has a direct impact on that. The protocol should not > require nor give preference to any one particular client architecture, > in the same way as we seek not to hardwire any single choice of > server-side deployment pattern. It seems reasonable to apply this > same philosophy to the client endpoint, so that the protocol can allow > for many different kinds of client-side deployment. > > Midway through the two years of operation of the Architecture Working > Group in SL, we explored a variety of client-side scenarios, including > this design for a multi-process client > > . This split out all functional parts of a client into separate > processes, all interconnected through a "Mediator" hub process via > sockets, while also accepting point-to-point and shared-memory > communication paths as accelerators between subprocesses where > required for speed. > > Such a client architecture is a perfect match for this new age of > multicore, among a huge list of other benefits enumerated on that > page. It can be considered the fully distributed end of the large > spectrum of possible clients. Lawson's SL client- Squeak bridge > represents another split, libomv's gridproxy > and its Jabber plugin > shows > another, while LL's own system for media plugins is yet another. All > these moves take us away from the notion of a VW client being a > monolithic entity, and correspondingly, we should no longer assume > that the client-side protocol endpoint is monolithic either. > > To that end, it might be an effective approach to model VWRAP as a > /protocol over sets of sources and sinks for data/. One set is > server-side, which we are already modelling as a multiplicity of > service endpoints, and another set is client-side, representing the > many subsystems that deal with different aspects of interacting with > VW worlds and talking to their services. Those subsystems are clear > candidates for distinct protocol endpoints of their own. > > Such a model would more accurately reflect how client applications are > actually built (in other words, in a modular fashion), instead of > funneling everything through a single client-side endpoint. The > current single-client-endpoint approach is hardwiring an unnecessary > bottleneck into the client model, as well as encouraging a poor design > for clients through making all data appear at a single doorway. > > Perhaps we need to reflect on this a little before rushing ahead with > yesterday's design philosophy for protocol endpoints. > > > Morgaine. > > > > > > ================================= > > On Sat, Dec 5, 2009 at 2:00 PM, Lawson English > wrote: > > All this goes back to what I just posted on the SLDEV list about > taking initiative and coding something up. Having the ability for > clients to talk to each other rather than some 3rd party service > might blur the line concerning what VWRAP is supposed to be > talking about, but, IMHO, the line is getting blurred anyway. > > What's the difference between a plugin sitting on someone's > desktop in order to augment the client in some way, and a plugin > that actually allows clients to talk to each other directly in > order to collectively augment them in some way? As far as I'm > concerned, these discussions about clients talking to each other > are just extensions totalks about what responsibilities client > plugins might have. > > My current project is based on this idea: > > http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin > > I'm writing a SL client- squeak bridge (starting off easy with a > port of my do-nothing Python client for practice) that will allow > me to test new client plugin ideas. The Holy Grail for the project > will be to integrate Cobalt/Croquet with SL in some way(s) and > that is just the tip of an iceberg that is being held under water > by a large outcropping of land. There's more potential in > P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR VWRAP > (clear-cut client-server worlds) taken separately. While > VWRAP/OGP/whatever's charter may not consider the P2P approach as > relevant, the fact is, P2P is potentially in ANY extension of > services involving clients which aren't talking exclusively to an > old school SL simulator. > > > Lawson > > > > > Carlo Wood wrote: > > On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: > > > With all due respect, Carlo, I am finding that I disagree > with your analysis. > > > > There is no analysis.. it is something has been said before > on the list: if YOU don't want something, then that doesn't > mean there will be no need for it in the future by others. > > You shouldn't take YOUR experience and desires and then say: > "we will never need this, NOBODY will EVER need this", > while it's relatively easy and simple to add the *support* > for it to the protocol! > > By adding the *possibility* for viewers to wait for others, > you do not force anyone to do it different from what you > describe. But you also don't take away the possibility to > do it how other people WANT it (like me, I personally think > this is important - so thus far we have a 50% - 50% vote for > the NEED of this wait feature). > > So, to be really undiplomatic blunt: who are you to deny > me this experience? While adding just a little to the protocol > we BOTH can be happy? You can do it your way, and I can do it > my way? But you say: "You don't need it" and want to remove > the possibility from the protocol so that you can do it your > way and I CANNOT do it the way I want ?! > > THAT is the reasoning behind NOT leaving out rather trivial > options to the protocol. And really, this has been said on > the list before a few times imho (and no, I'm not going to > find that back). > > > > I have a lot of practical experience in SL getting animations > as well as sound and textures to synchronize under a lot > of different conditions by taking into account the > client's existing > cacheing behavior. I'm drawing on that experience for my > assertions. > > > > I am too, and I say I need this. > > > > I can't think of a single reasonable use case that would > *require* clients > to hold for the slowest link. The examples you have suggested > > > > I can. > > > > don't require it to achieve the outcome you desire. > > > ??? Then you didn't read very well what I said. > If you want to do what I said then you *NEED* the possibility > to wait > for other (some) clients (some limited time), and why not, > have the > possibility to abort, or continue anyway (as you want). > > Having those options you can synchronize the experience well > within > lag-time, well within typing-delay time (ie, under 1 second). > If you > don't wait, the playing time could run up till 30 seconds or more! > > Having those options you can synchronize the experience well > within > 1 second AND you can do what you want: just state don't wait > for anyone > and play stuff the second you get it. > > [...] > > > So here I'll walk through an example... the hug: > > To synchronize a hug all that is needed is for the > > > "all that is needed" to accomplish YOUR needs and views. > For me, I realllllly need to know when other clients are > ready too. > > [...snip...] > > > be longer for some clients than others. The exact wall > clock delay does not > matter since the end user has no idea when the event was > actually sent. > > > > Yes we totally disagree here, and you are wrong: there are > many other > shared experiences (typed text, and remaining movement of the > avatar > before and after; not to mention voice chat) that need to be > more or > less in sync with gestures; the user WILL have an idea when > the event > was sent. > > The wall clock DOES matter - certainly when the delay can run > up to a whole minute. > > You are "right" for delays less than a second, and I argue > that we should try hard to get the shared experience synchronized > within one second IF THE USER(S) SO DESIRE. > > I already gave you examples where it is notable when the delay > is larger, but I guess every example is personal. If YOU don't > care that your friends see you bolt for the door and once outside > you jump and shout "Whooohooo!", while you really intended to > first jump and shout and THEN run for the door, then well-- > that is entirely your choice. Now let me, and others, have mine. > > Another example, your hug: You initiate a hug request (your client > already has the needed assets or starts to download them > immediately). > By the time that your partner clicks 'Ok', your viewer is ready > and immediately starts to play the hug. While hugging you say: > "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees > that text while they don't see you hugging yet; others do however. > Because others DO, we NEED support in the protocol to know when > other clients are ready (at least, have all the needed data > cached; any other delay is too short to be bothered with-- I'm > with you on that then). > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > ------------------------------------------------------------------------ > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Sun Dec 6 09:12:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772B23A6864 for ; Sun, 6 Dec 2009 09:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eE3hBjJjBFT for ; Sun, 6 Dec 2009 09:12:06 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 1F6943A6909 for ; Sun, 6 Dec 2009 09:12:04 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so255192eyd.51 for ; Sun, 06 Dec 2009 09:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Howy5qPoq4ASc6ivnR2HvAjoEISq7ywzkWXaJL9YXGk=; b=UQvBkuwj4LaEhvMKh3FFVbJuKb0KIawh2l0YG8mRE7guOyi5W3Ar+JVB5FKGj3VoHG JdLi4Aw4HzCkDBK4GAF+qJbJEd8i8jbD61FBsxxhtBtZUuOF6HV3y9FmDvWHT18l43aa dBkZfukDmsxis52Rzgg/+KVf38rMOAlyiPs4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=JLFasNU7NsWxyQ/HpHwYpA4VYSHOK53W0XnlaYUZ9DJWL7w95N7zSgKT3BxmzK5ObC M4159vGhEasZvk/KuYhn82f5wEji8YbiUkDLZKYVrNdcYOBymEzrBXI7diFs7/dD/7Qv bghbeUWIbHd8eK6T6CY+n7AYSaDr5mMtFG+DQ= MIME-Version: 1.0 Received: by 10.216.89.70 with SMTP id b48mr727119wef.160.1260119511950; Sun, 06 Dec 2009 09:11:51 -0800 (PST) In-Reply-To: <4B1B785A.9000602@cox.net> References: <4B1B785A.9000602@cox.net> Date: Sun, 6 Dec 2009 17:11:51 +0000 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6d9a327e266a4047a126f2a Subject: Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 17:12:09 -0000 --0016e6d9a327e266a4047a126f2a Content-Type: text/plain; charset=ISO-8859-1 >From a protocol perspective, the key observation in this area is that different data paths from VWRAP services to the client no longer all terminate in the same client-side process --- that is only one extreme end of the possible spectrum of implementations. In today's concurrent execution environment, the "application" may comprise multiple processes on the same client-side host, or be distributed across several client-side hosts (either virtualized or real), and quite possibly involve multiple remote hosts on the Internet as well. The concept of "application" has broadened since its early years, in part because of the arrival of multicore, and in part because of ever-growing user expectations fueled by the Internet and social networking. It's not up to us to prejudge nor prescribe how VW applications will be structured. The fact that advanced ones will involve multiple disjoint processes is a given, and our protocol endpoint design must take that into account, or it will be obsolete before it is even ready. Fortunately, the capability model embraces this concept perfectly. Having acquired a capability from an AD or from an RD, this capability represents all that is needed for anyone to perform whatever action is controlled by that capability --- it does not prescribe *who* may do so. That capability can (in *principle*) be passed around or copied to any other party whom the original acquirer permits to carry out that action for them. Unfortunately, practice does not always follow principle, and a bad implementation of capabilities could prevent a capability being expressed by any party except the party to whom it was granted. That would be a corruption of the concept of "capability" as a rights token, confusing its clean semantics with those of the endpoint-permission model that capabilities were designed to improve. It's not easy to identify what our early specs offer on this score, since they seem to assume a single client-side endpoint but don't actually address the issue --- it appears that they were drafted against a background of the original monolithic client application representing the "norm". This will have to be examined in more detail to prevent newer non-monolithic clients from being constrained by that original implementation. Does anyone know of any current restrictions on acquiring a capability from one host IP address but using it from another address, or acquiring it from one source port but using it from another source port on the same host address? (The latter is the single-host, multi-process scenario.) Morgaine. ====================================== On Sun, Dec 6, 2009 at 9:24 AM, Lawson English wrote: > Thanks Morgaine. The concept of a plugin-driven client is simply your > modular client idea built off of the existing LL client. > > The final extension of your client is a collection of interacting plugins > with a central mediator and possibly connections between plugins and/or > services that bypass the mediator. So the network looks like a star network > of plugins with a central mediator and a conduit of connections between > plugins and services. The final design would make the mediator an optional > central point to establish new connections, and process scripting/macro/GUI > commands, while the actual functions are carried out by the outlying > modules, which may not even be on the same computer. Similarly, the "server" > side might be equally as distributed and the distinction between client and > server disappears completely with clients handling some 3D element > generation and physics and assets, etc, while the server broadcasts 2D > mashups of the client's perspective to cell phones. > > Etc. > > So at one end, we have pure client-server designs like Second Life, at the > other extreme, purely p2p worlds like Croquet, and every possible > combination/permutation in-between. > > Lawson > > > > Morgaine wrote: > >> I agree with Lawson, but the topic goes far beyond gestures, so this is a >> new thread. >> >> Putting it another way, the days of the monolithic client are over, in the >> same way as the days of the walled garden and single service provider are >> over. >> >> In VWRAP, we are formalizing the unbundling of service provision so that >> server-side is becoming distributed, but we don't seem to have grasped the >> corresponding concept of non-monolithic clients yet. Perhaps the client >> needs more flexibility than we are currently considering. >> >> Although we are not dealing with client application architecture here, we >> /are/ dealing with protocol endpoint architecture, and the design of clients >> has a direct impact on that. The protocol should not require nor give >> preference to any one particular client architecture, in the same way as we >> seek not to hardwire any single choice of server-side deployment pattern. >> It seems reasonable to apply this same philosophy to the client endpoint, >> so that the protocol can allow for many different kinds of client-side >> deployment. >> >> Midway through the two years of operation of the Architecture Working >> Group in SL, we explored a variety of client-side scenarios, including this >> design for a multi-process client < >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft> . >> This split out all functional parts of a client into separate processes, >> all interconnected through a "Mediator" hub process via sockets, while also >> accepting point-to-point and shared-memory communication paths as >> accelerators between subprocesses where required for speed. >> >> Such a client architecture is a perfect match for this new age of >> multicore, among a huge list of other benefits enumerated on that page. It >> can be considered the fully distributed end of the large spectrum of >> possible clients. Lawson's SL client- Squeak bridge represents another >> split, libomv's gridproxy and >> its Jabber plugin < >> http://forge.opensimulator.org/gf/project/jabberimproxy/> shows another, >> while LL's own system for media plugins is yet another. All these moves >> take us away from the notion of a VW client being a monolithic entity, and >> correspondingly, we should no longer assume that the client-side protocol >> endpoint is monolithic either. >> >> >> To that end, it might be an effective approach to model VWRAP as a >> /protocol over sets of sources and sinks for data/. One set is server-side, >> which we are already modelling as a multiplicity of service endpoints, and >> another set is client-side, representing the many subsystems that deal with >> different aspects of interacting with VW worlds and talking to their >> services. Those subsystems are clear candidates for distinct protocol >> endpoints of their own. >> >> Such a model would more accurately reflect how client applications are >> actually built (in other words, in a modular fashion), instead of funneling >> everything through a single client-side endpoint. The current >> single-client-endpoint approach is hardwiring an unnecessary bottleneck into >> the client model, as well as encouraging a poor design for clients through >> making all data appear at a single doorway. >> >> Perhaps we need to reflect on this a little before rushing ahead with >> yesterday's design philosophy for protocol endpoints. >> >> >> Morgaine. >> >> >> >> >> >> ================================= >> >> On Sat, Dec 5, 2009 at 2:00 PM, Lawson English > lenglish5@cox.net>> wrote: >> >> All this goes back to what I just posted on the SLDEV list about >> taking initiative and coding something up. Having the ability for >> clients to talk to each other rather than some 3rd party service >> might blur the line concerning what VWRAP is supposed to be >> talking about, but, IMHO, the line is getting blurred anyway. >> >> What's the difference between a plugin sitting on someone's >> desktop in order to augment the client in some way, and a plugin >> that actually allows clients to talk to each other directly in >> order to collectively augment them in some way? As far as I'm >> concerned, these discussions about clients talking to each other >> are just extensions totalks about what responsibilities client >> plugins might have. >> >> My current project is based on this idea: >> >> >> http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin >> >> I'm writing a SL client- squeak bridge (starting off easy with a >> port of my do-nothing Python client for practice) that will allow >> me to test new client plugin ideas. The Holy Grail for the project >> will be to integrate Cobalt/Croquet with SL in some way(s) and >> that is just the tip of an iceberg that is being held under water >> by a large outcropping of land. There's more potential in >> P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR VWRAP >> (clear-cut client-server worlds) taken separately. While >> VWRAP/OGP/whatever's charter may not consider the P2P approach as >> relevant, the fact is, P2P is potentially in ANY extension of >> services involving clients which aren't talking exclusively to an >> old school SL simulator. >> >> >> Lawson >> >> >> >> >> Carlo Wood wrote: >> >> On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: >> >> With all due respect, Carlo, I am finding that I disagree >> with your analysis. >> >> >> There is no analysis.. it is something has been said before >> on the list: if YOU don't want something, then that doesn't >> mean there will be no need for it in the future by others. >> >> You shouldn't take YOUR experience and desires and then say: >> "we will never need this, NOBODY will EVER need this", >> while it's relatively easy and simple to add the *support* >> for it to the protocol! >> >> By adding the *possibility* for viewers to wait for others, >> you do not force anyone to do it different from what you >> describe. But you also don't take away the possibility to >> do it how other people WANT it (like me, I personally think >> this is important - so thus far we have a 50% - 50% vote for >> the NEED of this wait feature). >> >> So, to be really undiplomatic blunt: who are you to deny >> me this experience? While adding just a little to the protocol >> we BOTH can be happy? You can do it your way, and I can do it >> my way? But you say: "You don't need it" and want to remove >> the possibility from the protocol so that you can do it your >> way and I CANNOT do it the way I want ?! >> >> THAT is the reasoning behind NOT leaving out rather trivial >> options to the protocol. And really, this has been said on >> the list before a few times imho (and no, I'm not going to >> find that back). >> >> >> I have a lot of practical experience in SL getting animations >> as well as sound and textures to synchronize under a lot >> of different conditions by taking into account the >> client's existing >> cacheing behavior. I'm drawing on that experience for my >> assertions. >> >> >> I am too, and I say I need this. >> >> >> I can't think of a single reasonable use case that would >> *require* clients >> to hold for the slowest link. The examples you have suggested >> >> >> I can. >> >> >> don't require it to achieve the outcome you desire. >> >> ??? Then you didn't read very well what I said. >> If you want to do what I said then you *NEED* the possibility >> to wait >> for other (some) clients (some limited time), and why not, >> have the >> possibility to abort, or continue anyway (as you want). >> >> Having those options you can synchronize the experience well >> within >> lag-time, well within typing-delay time (ie, under 1 second). >> If you >> don't wait, the playing time could run up till 30 seconds or more! >> >> Having those options you can synchronize the experience well >> within >> 1 second AND you can do what you want: just state don't wait >> for anyone >> and play stuff the second you get it. >> >> [...] >> >> So here I'll walk through an example... the hug: >> >> To synchronize a hug all that is needed is for the >> >> "all that is needed" to accomplish YOUR needs and views. >> For me, I realllllly need to know when other clients are >> ready too. >> >> [...snip...] >> >> be longer for some clients than others. The exact wall >> clock delay does not >> matter since the end user has no idea when the event was >> actually sent. >> >> >> Yes we totally disagree here, and you are wrong: there are >> many other >> shared experiences (typed text, and remaining movement of the >> avatar >> before and after; not to mention voice chat) that need to be >> more or >> less in sync with gestures; the user WILL have an idea when >> the event >> was sent. >> >> The wall clock DOES matter - certainly when the delay can run >> up to a whole minute. >> >> You are "right" for delays less than a second, and I argue >> that we should try hard to get the shared experience synchronized >> within one second IF THE USER(S) SO DESIRE. >> >> I already gave you examples where it is notable when the delay >> is larger, but I guess every example is personal. If YOU don't >> care that your friends see you bolt for the door and once outside >> you jump and shout "Whooohooo!", while you really intended to >> first jump and shout and THEN run for the door, then well-- >> that is entirely your choice. Now let me, and others, have mine. >> >> Another example, your hug: You initiate a hug request (your client >> already has the needed assets or starts to download them >> immediately). >> By the time that your partner clicks 'Ok', your viewer is ready >> and immediately starts to play the hug. While hugging you say: >> "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees >> that text while they don't see you hugging yet; others do however. >> Because others DO, we NEED support in the protocol to know when >> other clients are ready (at least, have all the needed data >> cached; any other delay is too short to be bothered with-- I'm >> with you on that then). >> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > --0016e6d9a327e266a4047a126f2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From a protocol perspective, the key observation in this area is that diffe= rent data paths from VWRAP services to the client no longer all terminate i= n the same client-side process --- that is only one extreme end of the poss= ible spectrum of implementations.

In today's concurrent execution environment, the "application&= quot; may comprise multiple processes on the same client-side host, or be d= istributed across several client-side hosts (either virtualized or real), a= nd quite possibly involve multiple remote hosts on the Internet as well.=A0= The concept of "application" has broadened since its early years= , in part because of the arrival of multicore, and in part because of ever-= growing user expectations fueled by the Internet and social networking.

It's not up to us to prejudge nor prescribe how VW applications wil= l be structured.=A0 The fact that advanced ones will involve multiple disjo= int processes is a given, and our protocol endpoint design must take that i= nto account, or it will be obsolete before it is even ready.

Fortunately, the capability model embraces this concept perfectly.=A0 H= aving acquired a capability from an AD or from an RD, this capability repre= sents all that is needed for anyone to perform whatever action is controlle= d by that capability --- it does not prescribe who may do so.= =A0 That capability can (in principle) be passed around or copied t= o any other party whom the original acquirer permits to carry out that acti= on for them.

Unfortunately, practice does not always follow principle, and a bad imp= lementation of capabilities could prevent a capability being expressed by a= ny party except the party to whom it was granted.=A0 That would be a corrup= tion of the concept of "capability" as a rights token, confusing = its clean semantics with those of the endpoint-permission model that capabi= lities were designed to improve.

It's not easy to identify what our early specs offer on this score,= since they seem to assume a single client-side endpoint but don't actu= ally address the issue --- it appears that they were drafted against a back= ground of the original monolithic client application representing the "= ;norm".=A0 This will have to be examined in more detail to prevent new= er non-monolithic clients from being constrained by that original implement= ation.

Does anyone know of any current restrictions on acquiring a capability = from one host IP address but using it from another address, or acquiring it= from one source port but using it from another source port on the same hos= t address?=A0 (The latter is the single-host, multi-process scenario.)

Morgaine.

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

On Sun, Dec 6, 2009 at 9:= 24 AM, Lawson English <lenglish5@cox.net> wrote:

Thanks Morgaine. = The concept of a plugin-driven client is simply your modular client idea bu= ilt off of the existing LL client.

The final extension of your client is a collection of interacting plugins w= ith a central mediator and possibly =A0connections between plugins and/or s= ervices that bypass the mediator. So the network looks like a star network = of plugins with a central mediator and a conduit of connections between plu= gins and services. The final design would make the mediator an optional cen= tral point to establish new connections, and process scripting/macro/GUI co= mmands, while the actual functions are carried out by the outlying modules,= which may not even be on the same computer. Similarly, the "server&qu= ot; side might be equally as distributed and the distinction between client= and server disappears completely with clients handling some 3D element gen= eration and physics and assets, etc, while the server broadcasts 2D mashups= of the client's perspective to cell phones.

Etc.

So at one end, we have pure client-server designs like Second Life, at the = other extreme, purely p2p worlds like Croquet, and every possible combinati= on/permutation in-between.

Lawson

Morgaine wrote:

I agree with Lawson, but the topic goes far beyond gestures, so this is a n= ew thread.

Putting it another way, the days of the monolithic client are over, in the = same way as the days of the walled garden and single service provider are o= ver.

In VWRAP, we are formalizing the unbundling of service provision so that se= rver-side is becoming distributed, but we don't seem to have grasped th= e corresponding concept of non-monolithic clients yet. =A0Perhaps the clien= t needs more flexibility than we are currently considering.

Although we are not dealing with client application architecture here, we /= are/ dealing with protocol endpoint architecture, and the design of clients= has a direct impact on that. =A0The protocol should not require nor give p= reference to any one particular client architecture, in the same way as we = seek not to hardwire any single choice of server-side deployment pattern. = =A0It seems reasonable to apply this same philosophy to the client endpoint= , so that the protocol can allow for many different kinds of client-side de= ployment.

Midway through the two years of operation of the Architecture Working Group= in SL, we explored a variety of client-side scenarios, including this desi= gn for a multi-process client <https://wiki.second= life.com/wiki/Multi-Process_Client_VAG_--_draft> . =A0This split out= all functional parts of a client into separate processes, all interconnect= ed through a "Mediator" hub process via sockets, while also accep= ting point-to-point and shared-memory communication paths as accelerators b= etween subprocesses where required for speed.

Such a client architecture is a perfect match for this new age of multicore= , among a huge list of other benefits enumerated on that page. =A0It can be= considered the fully distributed end of the large spectrum of possible cli= ents. =A0Lawson's SL client- Squeak bridge represents another split, li= bomv's gridproxy <http://lib.openmetaverse.org/wiki/SLProxy> and= its Jabber plugin <http://forge.opensimulator.org/gf/projec= t/jabberimproxy/> shows another, while LL's own system for media= plugins is yet another. =A0All these moves take us away from the notion of= a VW client being a monolithic entity, and correspondingly, we should no l= onger assume that the client-side protocol endpoint is monolithic either.

To that end, it might be an effective approach to model VWRAP as a /protoco= l over sets of sources and sinks for data/. =A0One set is server-side, whic= h we are already modelling as a multiplicity of service endpoints, and anot= her set is client-side, representing the many subsystems that deal with dif= ferent aspects of interacting with VW worlds and talking to their services.= =A0Those subsystems are clear candidates for distinct protocol endpoints o= f their own.

Such a model would more accurately reflect how client applications are actu= ally built (in other words, in a modular fashion), instead of funneling eve= rything through a single client-side endpoint. =A0The current single-client= -endpoint approach is hardwiring an unnecessary bottleneck into the client = model, as well as encouraging a poor design for clients through making all = data appear at a single doorway.

Perhaps we need to reflect on this a little before rushing ahead with yeste= rday's design philosophy for protocol endpoints.

Morgaine.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Sat, Dec 5, 2009 at 2:00 PM, Lawson English <lenglish5@cox.net <mailto:lenglish5@cox.net>> w= rote:

=A0 =A0All this goes back to what I just posted on the SLDEV list about =A0 =A0taking initiative and coding something up. Having the ability for =A0 =A0clients to talk to each other rather than some 3rd party service =A0 =A0might blur the line concerning what VWRAP is supposed to be
=A0 =A0talking about, but, IMHO, the line is getting blurred anyway.

=A0 =A0What's the difference between a plugin sitting on someone's=
=A0 =A0desktop in order to augment the client in some way, and a plugin =A0 =A0that actually allows clients to talk to each other directly in
=A0 =A0order to collectively augment them in some way? As far as I'm =A0 =A0concerned, these discussions about clients talking to each other =A0 =A0are just extensions totalks about what responsibilities client
=A0 =A0plugins might have.

=A0 =A0My current project is based on this idea:

=A0 =A0http://= wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Ext= ension_to_Media_Plugin

=A0 =A0I'm writing a SL client- squeak bridge (starting off easy with = a
=A0 =A0port of my =A0do-nothing Python client for practice) that will allo= w
=A0 =A0me to test new client plugin ideas. The Holy Grail for the project<= br> =A0 =A0will be to integrate Cobalt/Croquet with SL in some way(s) and
=A0 =A0that is just the tip of an iceberg that is being held under water =A0 =A0by a large outcropping of land. There's more potential in
=A0 =A0P2P-VWRAP hybrids than there is in =A0P2P (Croquet/Cobalt) OR VWRAP=
=A0 =A0(clear-cut client-server worlds) taken separately. While
=A0 =A0VWRAP/OGP/whatever's charter may not consider the P2P approach = as
=A0 =A0relevant, the fact is, P2P is potentially in ANY extension of
=A0 =A0services involving clients which aren't talking exclusively to = an
=A0 =A0old school SL simulator.

=A0 =A0Lawson

=A0 =A0Carlo Wood wrote:

=A0 =A0 =A0 =A0On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:=
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0With all due respect, =A0Carlo, I am finding that I= disagree
=A0 =A0 =A0 =A0 =A0 =A0with your analysis.
=A0 =A0 =A0 =A0 =A0 =A0 =A0

=A0 =A0 =A0 =A0There is no analysis.. it is something has been said before=
=A0 =A0 =A0 =A0on the list: if YOU don't want something, then that doe= sn't
=A0 =A0 =A0 =A0mean there will be no need for it in the future by others.<= br>
=A0 =A0 =A0 =A0You shouldn't take YOUR experience and desires and then= say:
=A0 =A0 =A0 =A0"we will never need this, NOBODY will EVER need this&q= uot;,
=A0 =A0 =A0 =A0while it's relatively easy and simple to add the *suppo= rt*
=A0 =A0 =A0 =A0for it to the protocol!

=A0 =A0 =A0 =A0By adding the *possibility* for viewers to wait for others,=
=A0 =A0 =A0 =A0you do not force anyone to do it different from what you =A0 =A0 =A0 =A0describe. But you also don't take away the possibility = to
=A0 =A0 =A0 =A0do it how other people WANT it (like me, I personally think=
=A0 =A0 =A0 =A0this is important - so thus far we have a 50% - 50% vote fo= r
=A0 =A0 =A0 =A0the NEED of this wait feature).

=A0 =A0 =A0 =A0So, to be really undiplomatic blunt: who are you to deny =A0 =A0 =A0 =A0me this experience? While adding just a little to the proto= col
=A0 =A0 =A0 =A0we BOTH can be happy? You can do it your way, and I can do = it
=A0 =A0 =A0 =A0my way? But you say: "You don't need it" and = want to remove
=A0 =A0 =A0 =A0the possibility from the protocol so that you can do it you= r
=A0 =A0 =A0 =A0way and I CANNOT do it the way I want ?!

=A0 =A0 =A0 =A0THAT is the reasoning behind NOT leaving out rather trivial=
=A0 =A0 =A0 =A0options to the protocol. And really, this has been said on<= br> =A0 =A0 =A0 =A0the list before a few times imho (and no, I'm not going= to
=A0 =A0 =A0 =A0find that back).

=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0I have a lot of practical experience in SL getting = animations
=A0 =A0 =A0 =A0 =A0 =A0as well as sound and textures to synchronize under = a lot
=A0 =A0 =A0 =A0 =A0 =A0of different conditions by taking into account the<= br> =A0 =A0 =A0 =A0 =A0 =A0client's existing
=A0 =A0 =A0 =A0 =A0 =A0cacheing behavior. =A0 I'm drawing on that expe= rience for my
=A0 =A0 =A0 =A0 =A0 =A0assertions.
=A0 =A0 =A0 =A0 =A0 =A0 =A0

=A0 =A0 =A0 =A0I am too, and I say I need this.

=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0I can't think of a single reasonable use case t= hat would
=A0 =A0 =A0 =A0 =A0 =A0*require* clients
=A0 =A0 =A0 =A0 =A0 =A0to hold for the slowest link. =A0The examples you h= ave suggested
=A0 =A0 =A0 =A0 =A0 =A0 =A0

=A0 =A0 =A0 =A0I can.

=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0don't require it to achieve the outcome you des= ire. =A0 =A0

=A0 =A0 =A0 =A0??? Then you didn't read very well what I said.
=A0 =A0 =A0 =A0If you want to do what I said then you *NEED* the possibili= ty
=A0 =A0 =A0 =A0to wait
=A0 =A0 =A0 =A0for other (some) clients (some limited time), and why not,<= br> =A0 =A0 =A0 =A0have the
=A0 =A0 =A0 =A0possibility to abort, or continue anyway (as you want).

=A0 =A0 =A0 =A0Having those options you can synchronize the experience wel= l
=A0 =A0 =A0 =A0within
=A0 =A0 =A0 =A0lag-time, well within typing-delay time (ie, under 1 second= ).
=A0 =A0 =A0 =A0If you
=A0 =A0 =A0 =A0don't wait, the playing time could run up till 30 secon= ds or more!

=A0 =A0 =A0 =A0Having those options you can synchronize the experience wel= l
=A0 =A0 =A0 =A0within
=A0 =A0 =A0 =A01 second AND you can do what you want: just state don't= wait
=A0 =A0 =A0 =A0for anyone
=A0 =A0 =A0 =A0and play stuff the second you get it.

=A0 =A0 =A0 =A0[...]
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0So here I'll walk through an example... the hug= :

=A0 =A0 =A0 =A0 =A0 =A0To synchronize a hug all that is needed is for the = =A0 =A0

=A0 =A0 =A0 =A0"all that is needed" to accomplish YOUR needs and= views.
=A0 =A0 =A0 =A0For me, I realllllly need to know when other clients are =A0 =A0 =A0 =A0ready too.

=A0 =A0 =A0 =A0[...snip...]
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0be longer for some clients than others. =A0The exac= t wall
=A0 =A0 =A0 =A0 =A0 =A0clock delay does not
=A0 =A0 =A0 =A0 =A0 =A0matter since the end user has no idea when the even= t was
=A0 =A0 =A0 =A0 =A0 =A0actually sent.
=A0 =A0 =A0 =A0 =A0 =A0 =A0

=A0 =A0 =A0 =A0Yes we totally disagree here, and you are wrong: there are<= br> =A0 =A0 =A0 =A0many other
=A0 =A0 =A0 =A0shared experiences (typed text, and remaining movement of t= he
=A0 =A0 =A0 =A0avatar
=A0 =A0 =A0 =A0before and after; not to mention voice chat) that need to b= e
=A0 =A0 =A0 =A0more or
=A0 =A0 =A0 =A0less in sync with gestures; the user WILL have an idea when=
=A0 =A0 =A0 =A0the event
=A0 =A0 =A0 =A0was sent.

=A0 =A0 =A0 =A0The wall clock DOES matter - certainly when the delay can r= un
=A0 =A0 =A0 =A0up to a whole minute.

=A0 =A0 =A0 =A0You are "right" for delays less than a second, an= d I argue
=A0 =A0 =A0 =A0that we should try hard to get the shared experience synchr= onized
=A0 =A0 =A0 =A0within one second IF THE USER(S) SO DESIRE.

=A0 =A0 =A0 =A0I already gave you examples where it is notable when the de= lay
=A0 =A0 =A0 =A0is larger, but I guess every example is personal. If YOU do= n't
=A0 =A0 =A0 =A0care that your friends see you bolt for the door and once o= utside
=A0 =A0 =A0 =A0you jump and shout "Whooohooo!", while you really= intended to
=A0 =A0 =A0 =A0first jump and shout and THEN run for the door, then well--=
=A0 =A0 =A0 =A0that is entirely your choice. Now let me, and others, have = mine.

=A0 =A0 =A0 =A0Another example, your hug: You initiate a hug request (your= client
=A0 =A0 =A0 =A0already has the needed assets or starts to download them =A0 =A0 =A0 =A0immediately).
=A0 =A0 =A0 =A0By the time that your partner clicks 'Ok', your vie= wer is ready
=A0 =A0 =A0 =A0and immediately starts to play the hug. While hugging you s= ay:
=A0 =A0 =A0 =A0"Mmmmmmmmmmm, so nice". And YOU don't care if= your partner sees
=A0 =A0 =A0 =A0that text while they don't see you hugging yet; others = do however.
=A0 =A0 =A0 =A0Because others DO, we NEED support in the protocol to know = when
=A0 =A0 =A0 =A0other clients are ready (at least, have all the needed data=
=A0 =A0 =A0 =A0cached; any other delay is too short to be bothered with-- = I'm
=A0 =A0 =A0 =A0with you on that then).

=A0 =A0 =A0 =A0

=A0 =A0_______________________________________________
=A0 =A0ogpx mailing list

=A0 =A0ogpx@ietf.org <mailto:ogpx@ietf.o= rg>

=A0 =A0https://www.ietf.org/mailman/listinfo/ogpx

------------------------------------------------------------------------

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx
=A0

--0016e6d9a327e266a4047a126f2a-- From carlo@alinoe.com Sun Dec 6 16:20:21 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65803A69BC for ; Sun, 6 Dec 2009 16:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl6FocjUQcVh for ; Sun, 6 Dec 2009 16:20:19 -0800 (PST) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id E48493A69D0 for ; Sun, 6 Dec 2009 16:20:15 -0800 (PST) Received: from edge05.upc.biz ([192.168.13.212]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091207002004.XXFX10074.viefep15-int.chello.at@edge05.upc.biz> for ; Mon, 7 Dec 2009 01:20:04 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id E0L21d08F0FlQed050L31L; Mon, 07 Dec 2009 01:20:04 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NHRHj-0001QQ-PM for ogpx@ietf.org; Mon, 07 Dec 2009 01:17:03 +0100 Date: Mon, 7 Dec 2009 01:17:03 +0100 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20091207001703.GA26539@alinoe.com> References: <4B1B785A.9000602@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 00:20:21 -0000 On Sun, Dec 06, 2009 at 05:11:51PM +0000, Morgaine wrote: > It's not up to us to prejudge nor prescribe how VW applications will be > structured. The fact that advanced ones will involve multiple disjoint > processes is a given, and our protocol endpoint design must take that into > account, or it will be obsolete before it is even ready. I'd like to grab this opportunity to recall my proposal for client-server protocol negotiation. I really, really think that this is very important. If we could get the protocol completely right and finished the first time and it would never have to be changed again in the future, because it would suit every possible future demand and desire, then sure, we wouldn't need this... However, apart from that the fact that we'll make mistakes, we certainly can't predict what will be needed in the future! Therefore we really should allow for protocol changes by means of negotiation of optional and mandatory protocol features. I also think that we should use MY proposal for this negotiation; and not some other "protocol negotiation" that just won't cut it once things really start to change. To recall: * The protocol negotiation would allow to shift the protocol base over time to a COMPLETELY arbitrary new protocol (that garantees that any possible future demand CAN be met). * It is possible to keep backwards compatibility for as long as desired (ie, a few years), at which point old clients may be forced to upgrade if they lack then mandatory protocol features. * The proposal comes with a well thought-out sheme of distributed documentation of the protocol (extensions): For documentation purposes there would be the need for one central website having links to the websites of every administration with protocol extensions/enhancements (and from there to documentation of each feature separately). Leaving out the details for now, as they don't really matter imho. Not until we agree that this is something that we want. Having such negotiation defined, the protocol can and will be subject to an evolutionary process: Client coders will think of new features; certain VW's will implement and support those - and the best features will, under user demand, be copied by other grids. Once every grid uses some new feature and every viewer supports it, the feature can be made an integral part of the protocol as if it had been from the very start of it's design. As an example (from IRC (I have been the main developer and coder for undernet IRC for seven years)): In 1993 I introduced "Time Stamps" on undernet to battle net.riding. Today every IRC network uses time stamps, and it's unthinkable that IRC would work without. Other extensions that I added on top of the RFC which have slowly been copied by other networks*) are: bans stop every type of channel flooding; SILENCE stops private flooding at the server of the sender; delayed joins (to allow large event channels with thousands of listeners); "max targets" flood limiting (to slow down mass spamming to one message per 2 minutes); BURST message to synchronize channels on net.join atomically; numeric nicks to stop seven types of possible desyncs as a result of changing nicks in combination of MODE's, etc. But here it stopped... and left me very frustrated about the protocol: IT TURNED OUT TO BE IMPOSSIBLE TO MAKE NEEDED IMPROVEMENTS! Why? Because for subsequent essential improvements I needed to change the client-server protocol and that was IMPOSSIBLE because of the lack of a good client-server protocol negotiation. (After I left, this negotiation was added, but in a bad way, still not allowing for the changes that are really needed). -- Carlo Wood *) Not literally, but the Idea: each IRC network is a completely isolated set of servers, often running their own private server versions, so there is no need for any kind of compatibility there. That is different for the client-server protocol, since the SAME clients connect to different networks (but, as said before-- for a long time any such negotiation was lacking; resulting in hackish ways to "detect" on what network one was ('undernet', 'efnet', 'dalnet') and then guessing what features are needed (as no versioning was being done) for a long time, with uncontrolled wild growth as result. VWRAP will exist of many servers and viewers by *different* administrations/groups that all interconnect however! In that case a good protocol negotion sheme IS needed, from the very start! From carlo@alinoe.com Sun Dec 6 16:37:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E6E3A6892 for ; Sun, 6 Dec 2009 16:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeoigKaOXcv6 for ; Sun, 6 Dec 2009 16:37:05 -0800 (PST) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id C71A93A687C for ; Sun, 6 Dec 2009 16:37:04 -0800 (PST) Received: from edge02.upc.biz ([192.168.13.237]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091207003652.TIZM26374.viefep13-int.chello.at@edge02.upc.biz>; Mon, 7 Dec 2009 01:36:52 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id E0cp1d05m0FlQed020cqqg; Mon, 07 Dec 2009 01:36:52 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NHRXy-0001a9-MY; Mon, 07 Dec 2009 01:33:50 +0100 Date: Mon, 7 Dec 2009 01:33:50 +0100 From: Carlo Wood To: Suzy Deffeyes Message-ID: <20091207003350.GA5500@alinoe.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sldev@lists.secondlife.com" , ogpx@ietf.org Subject: Re: [ogpx] [sldev] Snowglobe on OpenSim grids X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 00:37:06 -0000 On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: > If the code defaults to the existing hardcoded amazon behavior if a > cap to map tiles is not returned, then it doesn't require a LL > protocol change. There will be a time that not all OTHER implementations (ie opensim) have implemented this; in which case the cap will fail. In that case we want to fall back to the OLD way maps worked, because that is what works on opensim, at least - on opensim. Hence, this would require "detection" of on which network we are, and then adjust the "protocol" as required... I just wrote a long post about this horror (believe, it will happen again and again and again and the list of this type of things will only get LONGER and LONGER!). What we need, from the very start, is a good protocol negotiation sheme added to VWRAP (the new name for OGP). The protocol negotion sheme that I have proposed would make it clear what the base protocol is (the mandatory features so to say), as each server implementation gets it's own label (ie, LindenLab and OpenSim (as well as version numbers of course)). Then you could indeed say: Hey, opensim doesn't offer the feature "NewMap", so we use the old style map. And, hey, LindenLab doesn't offer the feature "NewMapURL", so we just use the S3 url as fall back (for the mandatory "NewMap" feature). Also, "NewMap" is really optional at the moment (the 1.23 viewers don't use it)... If the protocol negotiation had already been in place, then LL would have added an optional "NewMap" feature, with documentation, at the same time that it became available. The 1.23 viewer would not have known what it was and wouldn't use it, snowglobe would and would use it. THEN, on opensim, snowglobe would see that there isn't an optional "NewMap" feature and would NOT use the new map style. This demonstrates the power, and need, for protocol negotiation. At some later date, LL would add support for the new map also to the official viewers and make the feature mandatory (so that everyone with a client that doesn't support it has to upgrade). With the protocol negotiation that I proposed, the whole "NewMap" option would disappear from the actual negotiation (the documentation would still be there though, on the net ;), as if it had been a part of the protocol like everything else mandatory (ie, support for teleporting). -- Carlo Wood From carlo@alinoe.com Sun Dec 6 16:40:27 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7CB3A687C for ; Sun, 6 Dec 2009 16:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD8jPAHNWvqg for ; Sun, 6 Dec 2009 16:40:26 -0800 (PST) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 3FC713A6868 for ; Sun, 6 Dec 2009 16:40:26 -0800 (PST) Received: from edge02.upc.biz ([192.168.13.237]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091207004015.YKQB10582.viefep18-int.chello.at@edge02.upc.biz>; Mon, 7 Dec 2009 01:40:15 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id E0gD1d0750FlQed020gEeW; Mon, 07 Dec 2009 01:40:15 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NHRbH-0001cD-25; Mon, 07 Dec 2009 01:37:15 +0100 Date: Mon, 7 Dec 2009 01:37:15 +0100 From: Carlo Wood To: Lawson English Message-ID: <20091207003715.GA6192@alinoe.com> References: <4AF8ECDE.2010900@cox.net> <20091110201157.GA10861@alinoe.com> <20091110204155.GA5757@alinoe.com> <6831E988-D876-41A9-B8E3-6CA599519030@gmail.com> <20091205124052.GA9193@alinoe.com> <4B1A677B.4090204@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1A677B.4090204@cox.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] Synchronization of gestures X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 00:40:27 -0000 On Sat, Dec 05, 2009 at 07:00:27AM -0700, Lawson English wrote: > All this goes back to what I just posted on the SLDEV list about > taking initiative and coding something up. Having the ability for > clients to talk to each other rather than some 3rd party service > might blur the line concerning what VWRAP is supposed to be talking > about, but, IMHO, the line is getting blurred anyway. > > What's the difference between a plugin sitting on someone's desktop > in order to augment the client in some way, and a plugin that > actually allows clients to talk to each other directly in order to > collectively augment them in some way? As far as I'm concerned, > these discussions about clients talking to each other are just > extensions totalks about what responsibilities client plugins might > have. For the record, nowhere I proposed to let clients talk to eachother. It was my opinion that it is better to use the sim as trusted middle man for all of this. Someone sends a message to the sim, the sim sends a message to all clients (within relevant range), and then clients reacts back to the sim, who controls the decision making (based on the parameters of the initial message). Once the state becomes as requested, the sim sends again a message to all clients to inform that that the requested state has been reached (or one of the requested timeouts has been reached). This means, in the case of synchronized gestures, that the VWRAP protocol (client-server is also VWRAP no?) needs to support some parameters for this first message that allows a client to request the wanted strategy: a timeout per client at least. I think it will be sufficient to make a difference between the following groups of clients: 1) Those participating in the multi-animation 2) Those within X meters. 3) Those within chat distance 4) Those within shout distance 5) All others For each group, one could request a timeout as function of distance and parcel... etc. This would result in relative short messages (even with 100 avatars in one place) *) However, since all this information is already known to the client, it's possibly better to just send a complete list to the server with a fixed timeout for each client (of interest). Ie: GESTURE_REQUEST 20.0 uuid1 -1 uuid2 10.0 uuid2 10.0 uuid3 4.0 uuid4 2.5432 uuid5 1.5281 giving timeouts in seconds, -1 means wait forever (clients not mentioned would not be waited for). If uuid1 isn't ready within 20.0 seconds (the first parameter) the gesture is aborted. Those messages might be relative short too, if most viewers consider only a small number of clients relevant (ie: only mention "friends" within chat range). To those thinking that this "too" complex... Really... A computer has no problems with this "complexity" whatsoever. All that is needed is to think it over once, document it well, and then sit back and enjoy the flexibility and powerful possibilities for years and years that follow. -- Carlo Wood *) Ie, I would configure my client to wait 30 seconds for those participating in the animation, MIN(10, 40 / distance) seconds for those in the same parcel and within chat range. 25.2 / distance + 0.74 seconds for those in the same parcel but outside the chat range. 1.0 seconds for those outside the same parcel but within shout range, and not at all for those outside the parcel and outside the shout range. I'd only abort an animation when anyone participating in the animation would not be ready within 30 seconds, or when it was a gesture just for me and less than half of my friends within a range of 10 meter would not be ready within a time depending on the situation (ie, I'd configure the viewer to wait normally the usual time that it takes for anyone to download the assets, and then wait until at least all but one friend have the data... oh wait, for that I'd need to be informed about who is ready, when they are ready... From dwl@us.ibm.com Sun Dec 6 19:47:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2F828C0D8; Sun, 6 Dec 2009 19:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dBrBzVelhyC; Sun, 6 Dec 2009 19:47:02 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 594F93A67E9; Sun, 6 Dec 2009 19:46:59 -0800 (PST) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB73ZOKW019631; Sun, 6 Dec 2009 22:35:24 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB73kekQ117320; Sun, 6 Dec 2009 22:46:40 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB73kesY020603; Mon, 7 Dec 2009 01:46:40 -0200 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB73ketv020600; Mon, 7 Dec 2009 01:46:40 -0200 In-Reply-To: References: <4B1B785A.9000602@cox.net> To: Morgaine MIME-Version: 1.0 X-KeepSent: 4E68E078:42799DBF-85257685:000A0777; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sun, 6 Dec 2009 22:46:39 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/06/2009 22:46:39, Serialize complete at 12/06/2009 22:46:39 Content-Type: multipart/alternative; boundary="=_alternative 0014C08C85257685_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 03:47:05 -0000 This is a multipart message in MIME format. --=_alternative 0014C08C85257685_= Content-Type: text/plain; charset="US-ASCII" The current specs certainly are intended to be totally neutral on this. The only place I can see where one would have to pay attention would be in managing and establishing TLS pipes (HTTPS) and this is routinely done within web environments. As you observe, the semantic of capabilities is designed to support this. It would actually take some effort to break that semantic. That said, there are structures which work better, and worse, when they are widely distributed.Asset, Messaging, and Such distribute without much pain. The core state sharing application (What a region does for a living) is harder to spread out, and likewise, there are interesting synchronization challenges as you break apart client components. The less shared tasks (such as manipulating your inventory) are less sensitive. The data flows which manage the shared visual experience more so. >From the protocol perspective, I suggest the question is "Are there specific synchronization management issues we need to surface." I'm not expecting a lot, but if we know of some, we should get them on the table.I will also gently remind people of the notewell, when it comes to any IPR encumbered issues in this space. - David / Zha Morgaine Sent by: ogpx-bounces@ietf.org 12/06/2009 12:11 PM To ogpx@ietf.org cc Subject Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) >From a protocol perspective, the key observation in this area is that different data paths from VWRAP services to the client no longer all terminate in the same client-side process --- that is only one extreme end of the possible spectrum of implementations. In today's concurrent execution environment, the "application" may comprise multiple processes on the same client-side host, or be distributed across several client-side hosts (either virtualized or real), and quite possibly involve multiple remote hosts on the Internet as well. The concept of "application" has broadened since its early years, in part because of the arrival of multicore, and in part because of ever-growing user expectations fueled by the Internet and social networking. It's not up to us to prejudge nor prescribe how VW applications will be structured. The fact that advanced ones will involve multiple disjoint processes is a given, and our protocol endpoint design must take that into account, or it will be obsolete before it is even ready. Fortunately, the capability model embraces this concept perfectly. Having acquired a capability from an AD or from an RD, this capability represents all that is needed for anyone to perform whatever action is controlled by that capability --- it does not prescribe who may do so. That capability can (in principle) be passed around or copied to any other party whom the original acquirer permits to carry out that action for them. Unfortunately, practice does not always follow principle, and a bad implementation of capabilities could prevent a capability being expressed by any party except the party to whom it was granted. That would be a corruption of the concept of "capability" as a rights token, confusing its clean semantics with those of the endpoint-permission model that capabilities were designed to improve. It's not easy to identify what our early specs offer on this score, since they seem to assume a single client-side endpoint but don't actually address the issue --- it appears that they were drafted against a background of the original monolithic client application representing the "norm". This will have to be examined in more detail to prevent newer non-monolithic clients from being constrained by that original implementation. Does anyone know of any current restrictions on acquiring a capability from one host IP address but using it from another address, or acquiring it from one source port but using it from another source port on the same host address? (The latter is the single-host, multi-process scenario.) Morgaine. ====================================== On Sun, Dec 6, 2009 at 9:24 AM, Lawson English wrote: Thanks Morgaine. The concept of a plugin-driven client is simply your modular client idea built off of the existing LL client. The final extension of your client is a collection of interacting plugins with a central mediator and possibly connections between plugins and/or services that bypass the mediator. So the network looks like a star network of plugins with a central mediator and a conduit of connections between plugins and services. The final design would make the mediator an optional central point to establish new connections, and process scripting/macro/GUI commands, while the actual functions are carried out by the outlying modules, which may not even be on the same computer. Similarly, the "server" side might be equally as distributed and the distinction between client and server disappears completely with clients handling some 3D element generation and physics and assets, etc, while the server broadcasts 2D mashups of the client's perspective to cell phones. Etc. So at one end, we have pure client-server designs like Second Life, at the other extreme, purely p2p worlds like Croquet, and every possible combination/permutation in-between. Lawson Morgaine wrote: I agree with Lawson, but the topic goes far beyond gestures, so this is a new thread. Putting it another way, the days of the monolithic client are over, in the same way as the days of the walled garden and single service provider are over. In VWRAP, we are formalizing the unbundling of service provision so that server-side is becoming distributed, but we don't seem to have grasped the corresponding concept of non-monolithic clients yet. Perhaps the client needs more flexibility than we are currently considering. Although we are not dealing with client application architecture here, we /are/ dealing with protocol endpoint architecture, and the design of clients has a direct impact on that. The protocol should not require nor give preference to any one particular client architecture, in the same way as we seek not to hardwire any single choice of server-side deployment pattern. It seems reasonable to apply this same philosophy to the client endpoint, so that the protocol can allow for many different kinds of client-side deployment. Midway through the two years of operation of the Architecture Working Group in SL, we explored a variety of client-side scenarios, including this design for a multi-process client < https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft> . This split out all functional parts of a client into separate processes, all interconnected through a "Mediator" hub process via sockets, while also accepting point-to-point and shared-memory communication paths as accelerators between subprocesses where required for speed. Such a client architecture is a perfect match for this new age of multicore, among a huge list of other benefits enumerated on that page. It can be considered the fully distributed end of the large spectrum of possible clients. Lawson's SL client- Squeak bridge represents another split, libomv's gridproxy and its Jabber plugin < http://forge.opensimulator.org/gf/project/jabberimproxy/> shows another, while LL's own system for media plugins is yet another. All these moves take us away from the notion of a VW client being a monolithic entity, and correspondingly, we should no longer assume that the client-side protocol endpoint is monolithic either. To that end, it might be an effective approach to model VWRAP as a /protocol over sets of sources and sinks for data/. One set is server-side, which we are already modelling as a multiplicity of service endpoints, and another set is client-side, representing the many subsystems that deal with different aspects of interacting with VW worlds and talking to their services. Those subsystems are clear candidates for distinct protocol endpoints of their own. Such a model would more accurately reflect how client applications are actually built (in other words, in a modular fashion), instead of funneling everything through a single client-side endpoint. The current single-client-endpoint approach is hardwiring an unnecessary bottleneck into the client model, as well as encouraging a poor design for clients through making all data appear at a single doorway. Perhaps we need to reflect on this a little before rushing ahead with yesterday's design philosophy for protocol endpoints. Morgaine. ================================= On Sat, Dec 5, 2009 at 2:00 PM, Lawson English > wrote: All this goes back to what I just posted on the SLDEV list about taking initiative and coding something up. Having the ability for clients to talk to each other rather than some 3rd party service might blur the line concerning what VWRAP is supposed to be talking about, but, IMHO, the line is getting blurred anyway. What's the difference between a plugin sitting on someone's desktop in order to augment the client in some way, and a plugin that actually allows clients to talk to each other directly in order to collectively augment them in some way? As far as I'm concerned, these discussions about clients talking to each other are just extensions totalks about what responsibilities client plugins might have. My current project is based on this idea: http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin I'm writing a SL client- squeak bridge (starting off easy with a port of my do-nothing Python client for practice) that will allow me to test new client plugin ideas. The Holy Grail for the project will be to integrate Cobalt/Croquet with SL in some way(s) and that is just the tip of an iceberg that is being held under water by a large outcropping of land. There's more potential in P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR VWRAP (clear-cut client-server worlds) taken separately. While VWRAP/OGP/whatever's charter may not consider the P2P approach as relevant, the fact is, P2P is potentially in ANY extension of services involving clients which aren't talking exclusively to an old school SL simulator. Lawson Carlo Wood wrote: On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote: With all due respect, Carlo, I am finding that I disagree with your analysis. There is no analysis.. it is something has been said before on the list: if YOU don't want something, then that doesn't mean there will be no need for it in the future by others. You shouldn't take YOUR experience and desires and then say: "we will never need this, NOBODY will EVER need this", while it's relatively easy and simple to add the *support* for it to the protocol! By adding the *possibility* for viewers to wait for others, you do not force anyone to do it different from what you describe. But you also don't take away the possibility to do it how other people WANT it (like me, I personally think this is important - so thus far we have a 50% - 50% vote for the NEED of this wait feature). So, to be really undiplomatic blunt: who are you to deny me this experience? While adding just a little to the protocol we BOTH can be happy? You can do it your way, and I can do it my way? But you say: "You don't need it" and want to remove the possibility from the protocol so that you can do it your way and I CANNOT do it the way I want ?! THAT is the reasoning behind NOT leaving out rather trivial options to the protocol. And really, this has been said on the list before a few times imho (and no, I'm not going to find that back). I have a lot of practical experience in SL getting animations as well as sound and textures to synchronize under a lot of different conditions by taking into account the client's existing cacheing behavior. I'm drawing on that experience for my assertions. I am too, and I say I need this. I can't think of a single reasonable use case that would *require* clients to hold for the slowest link. The examples you have suggested I can. don't require it to achieve the outcome you desire. ??? Then you didn't read very well what I said. If you want to do what I said then you *NEED* the possibility to wait for other (some) clients (some limited time), and why not, have the possibility to abort, or continue anyway (as you want). Having those options you can synchronize the experience well within lag-time, well within typing-delay time (ie, under 1 second). If you don't wait, the playing time could run up till 30 seconds or more! Having those options you can synchronize the experience well within 1 second AND you can do what you want: just state don't wait for anyone and play stuff the second you get it. [...] So here I'll walk through an example... the hug: To synchronize a hug all that is needed is for the "all that is needed" to accomplish YOUR needs and views. For me, I realllllly need to know when other clients are ready too. [...snip...] be longer for some clients than others. The exact wall clock delay does not matter since the end user has no idea when the event was actually sent. Yes we totally disagree here, and you are wrong: there are many other shared experiences (typed text, and remaining movement of the avatar before and after; not to mention voice chat) that need to be more or less in sync with gestures; the user WILL have an idea when the event was sent. The wall clock DOES matter - certainly when the delay can run up to a whole minute. You are "right" for delays less than a second, and I argue that we should try hard to get the shared experience synchronized within one second IF THE USER(S) SO DESIRE. I already gave you examples where it is notable when the delay is larger, but I guess every example is personal. If YOU don't care that your friends see you bolt for the door and once outside you jump and shout "Whooohooo!", while you really intended to first jump and shout and THEN run for the door, then well-- that is entirely your choice. Now let me, and others, have mine. Another example, your hug: You initiate a hug request (your client already has the needed assets or starts to download them immediately). By the time that your partner clicks 'Ok', your viewer is ready and immediately starts to play the hug. While hugging you say: "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees that text while they don't see you hugging yet; others do however. Because others DO, we NEED support in the protocol to know when other clients are ready (at least, have all the needed data cached; any other delay is too short to be bothered with-- I'm with you on that then). _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx ------------------------------------------------------------------------ _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0014C08C85257685_= Content-Type: text/html; charset="US-ASCII"
The current specs certainly are intended to be totally neutral on this. The only place I can see where one would have to pay attention would be in managing and establishing TLS pipes (HTTPS) and this is routinely done within web environments. As you observe, the semantic of capabilities is designed to support this. It would actually take some effort to break that semantic.

That said, there are structures which work better, and worse, when they are widely distributed.Asset, Messaging, and Such distribute without much pain. The core state sharing application (What a region does for a living) is harder to spread out, and likewise, there are interesting synchronization challenges as you break apart client components. The less shared tasks (such as manipulating your inventory) are less sensitive. The data flows which manage the shared visual experience more so.

From the protocol perspective, I suggest the question is "Are there specific synchronization management issues we need to surface." I'm not expecting a lot, but if we know of some, we should get them on the table.I will also gently remind people of the notewell, when it comes to
any IPR encumbered issues in this space.

- David / Zha

Morgaine <morgaine.dinova@googlemail.com>
Sent by: ogpx-bounces@ietf.org

12/06/2009 12:11 PM

To	ogpx@ietf.org
cc
Subject	Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures)

From a protocol perspective, the key observation in this area is that different data paths from VWRAP services to the client no longer all terminate in the same client-side process --- that is only one extreme end of the possible spectrum of implementations.

In today's concurrent execution environment, the "application" may comprise multiple processes on the same client-side host, or be distributed across several client-side hosts (either virtualized or real), and quite possibly involve multiple remote hosts on the Internet as well. The concept of "application" has broadened since its early years, in part because of the arrival of multicore, and in part because of ever-growing user expectations fueled by the Internet and social networking.

It's not up to us to prejudge nor prescribe how VW applications will be structured. The fact that advanced ones will involve multiple disjoint processes is a given, and our protocol endpoint design must take that into account, or it will be obsolete before it is even ready.

Fortunately, the capability model embraces this concept perfectly. Having acquired a capability from an AD or from an RD, this capability represents all that is needed for anyone to perform whatever action is controlled by that capability --- it does not prescribe who may do so. That capability can (in principle) be passed around or copied to any other party whom the original acquirer permits to carry out that action for them.

Unfortunately, practice does not always follow principle, and a bad implementation of capabilities could prevent a capability being expressed by any party except the party to whom it was granted. That would be a corruption of the concept of "capability" as a rights token, confusing its clean semantics with those of the endpoint-permission model that capabilities were designed to improve.

It's not easy to identify what our early specs offer on this score, since they seem to assume a single client-side endpoint but don't actually address the issue --- it appears that they were drafted against a background of the original monolithic client application representing the "norm". This will have to be examined in more detail to prevent newer non-monolithic clients from being constrained by that original implementation.

Does anyone know of any current restrictions on acquiring a capability from one host IP address but using it from another address, or acquiring it from one source port but using it from another source port on the same host address? (The latter is the single-host, multi-process scenario.)

Morgaine.

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

On Sun, Dec 6, 2009 at 9:24 AM, Lawson English <lenglish5@cox.net> wrote:
Thanks Morgaine. The concept of a plugin-driven client is simply your modular client idea built off of the existing LL client.

The final extension of your client is a collection of interacting plugins with a central mediator and possibly connections between plugins and/or services that bypass the mediator. So the network looks like a star network of plugins with a central mediator and a conduit of connections between plugins and services. The final design would make the mediator an optional central point to establish new connections, and process scripting/macro/GUI commands, while the actual functions are carried out by the outlying modules, which may not even be on the same computer. Similarly, the "server" side might be equally as distributed and the distinction between client and server disappears completely with clients handling some 3D element generation and physics and assets, etc, while the server broadcasts 2D mashups of the client's perspective to cell phones.

Etc.

So at one end, we have pure client-server designs like Second Life, at the other extreme, purely p2p worlds like Croquet, and every possible combination/permutation in-between.

Lawson

Morgaine wrote:
I agree with Lawson, but the topic goes far beyond gestures, so this is a new thread.

Putting it another way, the days of the monolithic client are over, in the same way as the days of the walled garden and single service provider are over.

In VWRAP, we are formalizing the unbundling of service provision so that server-side is becoming distributed, but we don't seem to have grasped the corresponding concept of non-monolithic clients yet. Perhaps the client needs more flexibility than we are currently considering.

Although we are not dealing with client application architecture here, we /are/ dealing with protocol endpoint architecture, and the design of clients has a direct impact on that. The protocol should not require nor give preference to any one particular client architecture, in the same way as we seek not to hardwire any single choice of server-side deployment pattern. It seems reasonable to apply this same philosophy to the client endpoint, so that the protocol can allow for many different kinds of client-side deployment.

Midway through the two years of operation of the Architecture Working Group in SL, we explored a variety of client-side scenarios, including this design for a multi-process client <https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft> . This split out all functional parts of a client into separate processes, all interconnected through a "Mediator" hub process via sockets, while also accepting point-to-point and shared-memory communication paths as accelerators between subprocesses where required for speed.

Such a client architecture is a perfect match for this new age of multicore, among a huge list of other benefits enumerated on that page. It can be considered the fully distributed end of the large spectrum of possible clients. Lawson's SL client- Squeak bridge represents another split, libomv's gridproxy <http://lib.openmetaverse.org/wiki/SLProxy> and its Jabber plugin <http://forge.opensimulator.org/gf/project/jabberimproxy/> shows another, while LL's own system for media plugins is yet another. All these moves take us away from the notion of a VW client being a monolithic entity, and correspondingly, we should no longer assume that the client-side protocol endpoint is monolithic either.

To that end, it might be an effective approach to model VWRAP as a /protocol over sets of sources and sinks for data/. One set is server-side, which we are already modelling as a multiplicity of service endpoints, and another set is client-side, representing the many subsystems that deal with different aspects of interacting with VW worlds and talking to their services. Those subsystems are clear candidates for distinct protocol endpoints of their own.

Such a model would more accurately reflect how client applications are actually built (in other words, in a modular fashion), instead of funneling everything through a single client-side endpoint. The current single-client-endpoint approach is hardwiring an unnecessary bottleneck into the client model, as well as encouraging a poor design for clients through making all data appear at a single doorway.

Perhaps we need to reflect on this a little before rushing ahead with yesterday's design philosophy for protocol endpoints.

Morgaine.

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

On Sat, Dec 5, 2009 at 2:00 PM, Lawson English <lenglish5@cox.net <mailto:lenglish5@cox.net>> wrote:

All this goes back to what I just posted on the SLDEV list about
taking initiative and coding something up. Having the ability for
clients to talk to each other rather than some 3rd party service
might blur the line concerning what VWRAP is supposed to be
talking about, but, IMHO, the line is getting blurred anyway.

What's the difference between a plugin sitting on someone's
desktop in order to augment the client in some way, and a plugin
that actually allows clients to talk to each other directly in
order to collectively augment them in some way? As far as I'm
concerned, these discussions about clients talking to each other
are just extensions totalks about what responsibilities client
plugins might have.

My current project is based on this idea:

http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin

I'm writing a SL client- squeak bridge (starting off easy with a
port of my do-nothing Python client for practice) that will allow
me to test new client plugin ideas. The Holy Grail for the project
will be to integrate Cobalt/Croquet with SL in some way(s) and
that is just the tip of an iceberg that is being held under water
by a large outcropping of land. There's more potential in
P2P-VWRAP hybrids than there is in P2P (Croquet/Cobalt) OR VWRAP
(clear-cut client-server worlds) taken separately. While
VWRAP/OGP/whatever's charter may not consider the P2P approach as
relevant, the fact is, P2P is potentially in ANY extension of
services involving clients which aren't talking exclusively to an
old school SL simulator.

Lawson

Carlo Wood wrote:

On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:

With all due respect, Carlo, I am finding that I disagree
with your analysis.

There is no analysis.. it is something has been said before
on the list: if YOU don't want something, then that doesn't
mean there will be no need for it in the future by others.

You shouldn't take YOUR experience and desires and then say:
"we will never need this, NOBODY will EVER need this",
while it's relatively easy and simple to add the *support*
for it to the protocol!

By adding the *possibility* for viewers to wait for others,
you do not force anyone to do it different from what you
describe. But you also don't take away the possibility to
do it how other people WANT it (like me, I personally think
this is important - so thus far we have a 50% - 50% vote for
the NEED of this wait feature).

So, to be really undiplomatic blunt: who are you to deny
me this experience? While adding just a little to the protocol
we BOTH can be happy? You can do it your way, and I can do it
my way? But you say: "You don't need it" and want to remove
the possibility from the protocol so that you can do it your
way and I CANNOT do it the way I want ?!

THAT is the reasoning behind NOT leaving out rather trivial
options to the protocol. And really, this has been said on
the list before a few times imho (and no, I'm not going to
find that back).

I have a lot of practical experience in SL getting animations
as well as sound and textures to synchronize under a lot
of different conditions by taking into account the
client's existing
cacheing behavior. I'm drawing on that experience for my
assertions.

I am too, and I say I need this.

I can't think of a single reasonable use case that would
*require* clients
to hold for the slowest link. The examples you have suggested

I can.

don't require it to achieve the outcome you desire.

??? Then you didn't read very well what I said.
If you want to do what I said then you *NEED* the possibility
to wait
for other (some) clients (some limited time), and why not,
have the
possibility to abort, or continue anyway (as you want).

Having those options you can synchronize the experience well
within
lag-time, well within typing-delay time (ie, under 1 second).
If you
don't wait, the playing time could run up till 30 seconds or more!

Having those options you can synchronize the experience well
within
1 second AND you can do what you want: just state don't wait
for anyone
and play stuff the second you get it.

[...]

So here I'll walk through an example... the hug:

To synchronize a hug all that is needed is for the

"all that is needed" to accomplish YOUR needs and views.
For me, I realllllly need to know when other clients are
ready too.

[...snip...]

be longer for some clients than others. The exact wall
clock delay does not
matter since the end user has no idea when the event was
actually sent.

Yes we totally disagree here, and you are wrong: there are
many other
shared experiences (typed text, and remaining movement of the
avatar
before and after; not to mention voice chat) that need to be
more or
less in sync with gestures; the user WILL have an idea when
the event
was sent.

The wall clock DOES matter - certainly when the delay can run
up to a whole minute.

You are "right" for delays less than a second, and I argue
that we should try hard to get the shared experience synchronized
within one second IF THE USER(S) SO DESIRE.

I already gave you examples where it is notable when the delay
is larger, but I guess every example is personal. If YOU don't
care that your friends see you bolt for the door and once outside
you jump and shout "Whooohooo!", while you really intended to
first jump and shout and THEN run for the door, then well--
that is entirely your choice. Now let me, and others, have mine.

Another example, your hug: You initiate a hug request (your client
already has the needed assets or starts to download them
immediately).
By the time that your partner clicks 'Ok', your viewer is ready
and immediately starts to play the hug. While hugging you say:
"Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees
that text while they don't see you hugging yet; others do however.
Because others DO, we NEED support in the protocol to know when
other clients are ready (at least, have all the needed data
cached; any other delay is too short to be bothered with-- I'm
with you on that then).

_______________________________________________
ogpx mailing list
ogpx@ietf.org <mailto:ogpx@ietf.org>

https://www.ietf.org/mailman/listinfo/ogpx

------------------------------------------------------------------------

_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx

_______________________________________________ ogpx mailing list ogpx@ietf.orghttps://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 0014C08C85257685_=-- From han.sontse.sl@gmail.com Sun Dec 6 21:20:13 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0FA3A68B4 for ; Sun, 6 Dec 2009 21:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehSGHqW3gCkf for ; Sun, 6 Dec 2009 21:20:11 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 8E0DF3A67A2 for ; Sun, 6 Dec 2009 21:20:11 -0800 (PST) Received: by pwi20 with SMTP id 20so971026pwi.29 for ; Sun, 06 Dec 2009 21:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=DOB918bKTe73N4kK+DlNjE33MnaCM7m9LUH1p1wJY14=; b=tLfxTf30xrOvgkPaVKgNhkdt2Dm01ZfZrQ03+zF0PFshnMdbdcrq+kB9QxR08fN8M+ URqUhvkb+onapTIiXuTqe8xcleLggv8f+dOPI+dtIwhkKR23fw8DmE4wpavWFeHGj8Vp XiHBckXfLx0MsV054FvJQsaDYwMp1gmgB8Plc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=p0hmL6/ScRrMXOx7OjxzWHd1estsWSbhEvdHV3oEmU/djv0H3hqnnVFLofpEFwFj81 IQI6mJS8zP/eVRbnAG9p53bbZwL9JeA47dbAYshr4EN6CCLE34hfBFScRs4/TOtNRE7N gI/0a1NYGQ4BGoeNTiNAZy9lFB7HjbR0/I5s0= Received: by 10.115.103.7 with SMTP id f7mr10822370wam.1.1260163198642; Sun, 06 Dec 2009 21:19:58 -0800 (PST) Received: from ?192.168.1.57? ([98.125.217.118]) by mx.google.com with ESMTPS id 20sm2017990pxi.15.2009.12.06.21.19.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Dec 2009 21:19:57 -0800 (PST) Message-Id: From: Han Sontse To: David W Levine , Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-535638649 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 6 Dec 2009 21:19:56 -0800 References: <4B1B785A.9000602@cox.net>

X-Mailer: Apple Mail (2.936) Cc: ogpx@ietf.org Subject: Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 05:20:13 -0000 --Apple-Mail-2-535638649 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 6, 2009, at 7:46 PM, David W Levine wrote: > > The current specs certainly are intended to be totally neutral on > this. The only place I can see where one would have to pay attention > would be in managing and establishing TLS pipes (HTTPS) and this is > routinely done within web environments. As you observe, the semantic > of capabilities is designed to support this. It would actually take > some effort to break that semantic. > > That said, there are structures which work better, and worse, when > they are widely distributed.Asset, Messaging, and Such distribute > without much pain. The core state sharing application (What a region > does for a living) is harder to spread out, and likewise, there are > interesting synchronization challenges as you break apart client > components. The less shared tasks (such as manipulating your > inventory) are less sensitive. The data flows which manage the > shared visual experience more so. > > From the protocol perspective, I suggest the question is "Are there > specific synchronization management issues we need to surface." I'm > not expecting a lot, but if we know of some, we should get them on > the table.I will also gently remind people of the notewell, when it > comes to > any IPR encumbered issues in this space. > > - David / Zha > Loosely speaking we need to be able to deal with a cloud-to-cloud relationship. This fuzzy notion seems to extend to client-clouds and server-clouds, as well as P2P clouds. To the extent that a given simulation space might contain other simulations, one could even consider each client as a server and each server as a client. maybe a way to begin to break down the complexity in these relationships it to look at the different classes of service that may be declared: Protocol constraints One-shot (UDP) simple Ack (UDP-UDP) Transactional short term (TCP) Complex (Multi-port/multi-host???) QoS Isochronous -- definite real time interval; predefined sequence order Synchronous -- predefined sequence ordering, indefinite time interval Asynchronous -- indefinite sequencing, indefinite timing Payload class declaration content streams parametric events bulk transfers OoB Signalling Payload structure declaration intrinsics (uint32, bool, etc) direct indirect structured complex Topology (Client and server are sub-classed peers) Ringed/chained P2P (a peer only knows 1 or 2 neighbors in the context) Open P2P( a peer knows all other peers in the context) Hierarchical P2P (peer knows a small set of super-peers and an arbitrary number of local peers) ??? and so on.... ~HS~ --Apple-Mail-2-535638649 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

On Dec 6, 2009, = at 7:46 PM, David W Levine wrote:

The current specs certainly are intended = to be totally neutral on this. The only place I can see where one would = have to pay attention would be in managing and establishing TLS pipes = (HTTPS) and this is routinely done within web environments. As you = observe, the semantic of capabilities is designed to support this. It = would actually take some effort to break that semantic.
=
That said, there are structures = which work better, and worse, when they are widely distributed.Asset, = Messaging, and Such distribute without much pain. The core state sharing = application (What a region does for a living) is harder to spread out, = and likewise, there are interesting synchronization challenges as you = break apart client components. The less shared tasks (such as = manipulating your inventory) are less sensitive. The data flows which = manage the shared visual experience more so.

=46rom the protocol perspective, I = suggest the question is "Are there specific synchronization management = issues we need to surface." I'm not expecting a lot, but if we know of = some, we should get them on the table.I will also gently remind people = of the notewell, when it comes to
any IPR encumbered issues in this space. =

- David / Zha
=

Loosely speaking we need to be able to = deal with a cloud-to-cloud relationship. This fuzzy notion seems = to extend to client-clouds and server-clouds, as well as P2P clouds. = To the extent that a given simulation space might contain other = simulations, one could even consider each client as a server and each = server as a client.

maybe a way to begin to = break down the complexity in these relationships it to look at the = different classes of service that may be = declared:

Protocol = constraints

One-shot (UDP)

simple Ack = (UDP-UDP)

Transactional short term (TCP)

Complex = (Multi-port/multi-host???)

QoS

Is= ochronous -- definite real time interval; predefined sequence = order

Synchronous -- predefined sequence ordering, = indefinite time interval

Asynchronous -- indefinite = sequencing, indefinite timing

Payload class = declaration

content streams

= parametric events

bulk transfers

OoB = Signalling

Payload structure = declaration

intrinsics (uint32, bool, = etc)

= direct

indirect

= structured

= complex

Topology (Client and server are = sub-classed peers)

Ringed/chained P2P (a peer = only knows 1 or 2 neighbors in the context)

Open P2P( = a peer knows all other peers in the context)

= Hierarchical P2P (peer knows a small set of super-peers and an = arbitrary number of local peers)

???

and = so on....

~HS~

= --Apple-Mail-2-535638649-- From josh@lindenlab.com Mon Dec 7 10:30:39 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FBB28C1DF for ; Mon, 7 Dec 2009 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mThmXGQLtcJU for ; Mon, 7 Dec 2009 10:30:39 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id E0BE53A691C for ; Mon, 7 Dec 2009 10:30:38 -0800 (PST) Received: by iwn39 with SMTP id 39so2949983iwn.32 for ; Mon, 07 Dec 2009 10:30:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.160.130 with SMTP id n2mr406481ibx.23.1260210625148; Mon, 07 Dec 2009 10:30:25 -0800 (PST) In-Reply-To: <20091207001703.GA26539@alinoe.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> Date: Mon, 7 Dec 2009 10:30:25 -0800 Message-ID: From: Joshua Bell To: Carlo Wood Content-Type: multipart/alternative; boundary=001636d3392ba7776f047a27a601 Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:30:40 -0000 --001636d3392ba7776f047a27a601 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2009 at 4:17 PM, Carlo Wood wrote: > > I'd like to grab this opportunity to recall my proposal for > client-server protocol negotiation. > Am I correct that this represents the previous discussion on the topic? Carlo's post: http://www.ietf.org/mail-archive/web/ogpx/current/msg00363.html Meadhbh's reply: http://www.ietf.org/mail-archive/web/ogpx/current/msg00362.html Can you respond to Meadhbh's comments? Dealing with version skew is addressed at various levels in the protocol drafts already, from presence/absence of named capabilities to HTTP nuances to LLSD semantic rules. That's not to say that this is sufficient, but it does appear to cover a broad spectrum of version skew issues, so identifying those that aren't covered - or those that could be addressed more explicitly with numbered versions - would be extremely valuable. Joshua --001636d3392ba7776f047a27a601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Dec 6, 2009 at 4:17 PM, Carlo Wood=C2=A0<= carlo@alinoe.com>=C2=A0wr= ote:

I'd like to grab this opportunity to recall my proposal for
clie= nt-server protocol negotiation.

A= m I correct that this represents the previous discussion on the topic?

Carlo's post:

http://www.= ietf.org/mail-archive/web/ogpx/current/msg00363.html

Meadhbh's reply:

http://www.ietf.org/mai= l-archive/web/ogpx/current/msg00362.html

Can you re= spond to Meadhbh's comments? Dealing with version skew is addressed at = various levels in the protocol drafts already, from presence/absence of nam= ed capabilities to HTTP nuances to LLSD semantic rules. That's not to s= ay that this is sufficient, but it does appear to cover a broad spectrum of= version skew issues, so identifying those that aren't covered - or tho= se that could be addressed more explicitly with numbered versions - would b= e extremely valuable.

Joshua

--001636d3392ba7776f047a27a601-- From meadhbh.siobhan@gmail.com Mon Dec 7 10:57:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEAF3A67EC for ; Mon, 7 Dec 2009 10:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtTIwgK27cbd for ; Mon, 7 Dec 2009 10:57:13 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 7A2193A67A8 for ; Mon, 7 Dec 2009 10:57:13 -0800 (PST) Received: by pzk6 with SMTP id 6so4099658pzk.29 for ; Mon, 07 Dec 2009 10:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+VyBDNtOZA0TXp558KMNiugJTu+WSM0vOVD8Rxdzso=; b=H7+FhGEX44ngG/yd2V3J9ebwPeLVF/j4PHIoL7UOwgaRWmCqvFaXkhWDfZSDtK3ksb USftQPsjRU+9zVzcMpLueL6YpDogSmeswlYEjEHE/3p++1zSegK3MDzkjQBNb9bMdB4D TX7q9vtyOKdj5dVRZ11NIgrp9IYAVxQ3bInsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rQ/vpztDSh2aY+XTxhGD6f0FouJtbwlCIdy9rLU6Ty1YJnMB4BeBzNR/iOvSCAifcn m4azGkfEjgWnM22NfPv5NfKXg0I8CXtQDkqzHIf2fRTzwqFbyHPqLN4uLQ1dkx5RO3zI urOAmevjrxlAhe1pQIQ0nBeVWmYKTC3OQ9Vf8= MIME-Version: 1.0 Received: by 10.115.100.22 with SMTP id c22mr938695wam.58.1260212220587; Mon, 07 Dec 2009 10:57:00 -0800 (PST) In-Reply-To: References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> Date: Mon, 7 Dec 2009 10:57:00 -0800 Message-ID: From: Meadhbh Hamrick To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:57:14 -0000 right. as i remember it (and i may be doing carlo's proposal a great disservice) the proposal is: a. at connection time, the client tells the server what new protocols it knows about. b. if the server doesn't know about the new protocols, then it uses the base protocol if so, we should also ask how this is different than a HTTP Upgrade. -cheers -meadhbh On Mon, Dec 7, 2009 at 10:30 AM, Joshua Bell wrote: > On Sun, Dec 6, 2009 at 4:17 PM, Carlo Wood=A0=A0wrote: >> >> I'd like to grab this opportunity to recall my proposal for >> client-server protocol negotiation. > > Am I correct that this represents the previous discussion on the topic? > Carlo's post: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00363.html > Meadhbh's reply: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00362.html > Can you respond to Meadhbh's comments? Dealing with version skew is > addressed at various levels in the protocol drafts already, from > presence/absence of named capabilities to HTTP nuances to LLSD semantic > rules. That's not to say that this is sufficient, but it does appear to > cover a broad spectrum of version skew issues, so identifying those that > aren't covered - or those that could be addressed more explicitly with > numbered versions - would be extremely valuable. > Joshua > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From carlo@alinoe.com Mon Dec 7 12:01:43 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6048328C1D6 for ; Mon, 7 Dec 2009 12:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqIly6MAJbci for ; Mon, 7 Dec 2009 12:01:42 -0800 (PST) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 13ED628C1A7 for ; Mon, 7 Dec 2009 12:01:41 -0800 (PST) Received: from edge03.upc.biz ([192.168.13.238]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091207200131.XAYD10074.viefep15-int.chello.at@edge03.upc.biz>; Mon, 7 Dec 2009 21:01:31 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id EL1T1d08m0FlQed03L1VSd; Mon, 07 Dec 2009 21:01:31 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NHjiz-0006H9-PF; Mon, 07 Dec 2009 20:58:25 +0100 Date: Mon, 7 Dec 2009 20:58:25 +0100 From: Carlo Wood To: Joshua Bell Message-ID: <20091207195825.GA23549@alinoe.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:01:43 -0000 On Mon, Dec 07, 2009 at 10:30:25AM -0800, Joshua Bell wrote: > Am I correct that this represents the previous discussion on the topic? > > Carlo's post: > > http://www.ietf.org/mail-archive/web/ogpx/current/msg00363.html > > Meadhbh's reply: > > http://www.ietf.org/mail-archive/web/ogpx/current/msg00362.html > > Can you respond to Meadhbh's comments? Dealing with version skew is addressed > at various levels in the protocol drafts already, from presence/absence of > named capabilities to HTTP nuances to LLSD semantic rules. That's not to say > that this is sufficient, but it does appear to cover a broad spectrum of > version skew issues, so identifying those that aren't covered - or those that > could be addressed more explicitly with numbered versions - would be extremely > valuable. Well, the more the protocol as-is allows corrections, improvements and extensions later on without the need for client (coders) to know what network/grid they are connected to, and/or what server versions are being used, because it will all "automatically" work out, the better! But-- it's very likely that not everything can be handled that way and that viewers will more and more have to fall back to kludgy heuristics to guess what new features are demanded or supported on the current grid they connect to. I state that we CANNOT know what changes of that type we will need in the future, I just know that it will happen; that we'll wish that a feature negotiation was in place from the beginning. As a coincidence (or is it really a coincidence...) right NOW we need this (see my other post): At the moment there is a need for a new capability (the url for the map). Working: * If the client doesn't know about it, it won't ask for it (check). * If the service doesn't know about it it won't return a capability. Not working: * In the latter case (the service not knowning about it) the viewer needs to fall back to the old style map on opensim and to a hardcoded S3 url on Second Life (which DOES support this capability, but just doesn't know about the "capability" url itself). * Once Linden Lab (or any other grid that will implement the same way that map works) stops supporting the "old style map", there is no way to tell the client explicit that THIS "feature" (the new way of how map works) is now mandatory, other than the existing method of requiring a minimal *viewer* version... which of course only works for the few viewers that are supported this way and which is a very crude way to state that one feature is now mandatory (bound to fail once there are lots of features like this to be negotiated). Sure, we can make this work-- in some kludgy way or another-- requiring hardcoding special cases and "grid detection" etc. But this is just one, or the first of many that will come, and to deal with that is neat and controlled way, we need protocol negotiation. If I'm wrong, and no protocol negotiation will ever be needed, then we will not have lost anything: the feature tables will just stay empty and there will not be anything to negotiate. No harm done. -- Carlo Wood From carlo@alinoe.com Mon Dec 7 12:18:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9996E3A692F for ; Mon, 7 Dec 2009 12:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFikJI1L8LGF for ; Mon, 7 Dec 2009 12:18:08 -0800 (PST) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 4E74A3A6808 for ; Mon, 7 Dec 2009 12:18:08 -0800 (PST) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091207201756.UQA21592.viefep11-int.chello.at@edge04.upc.biz>; Mon, 7 Dec 2009 21:17:56 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id ELHn1d01L0FlQed04LHoYi; Mon, 07 Dec 2009 21:17:56 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NHjym-0006T3-U6; Mon, 07 Dec 2009 21:14:44 +0100 Date: Mon, 7 Dec 2009 21:14:44 +0100 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20091207201444.GB23549@alinoe.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:18:09 -0000 On Mon, Dec 07, 2009 at 10:57:00AM -0800, Meadhbh Hamrick wrote: > right. as i remember it (and i may be doing carlo's proposal a great > disservice) the proposal is: > > a. at connection time, the client tells the server what new protocols > it knows about. > b. if the server doesn't know about the new protocols, then it uses > the base protocol > > if so, we should also ask how this is different than a HTTP Upgrade. The details are probably only important once we agree that this is needed (or at least handy to have :p)... Nevertheless, a better description would be: a. At connection time, the server tells the client what implementation it represents (ie "opensim" or "lindenlab") (called "label" below), it's protocol version, and a "compatibility version" (multiple label/version/compversion triplets may be provided). b. If the client knows about compversion or later for that implementation, then it proceeds; otherwise it would be incompatible (it will lack a feature that the service requires) and the user has to upgrade before they can connnect. c. Since the client knows (was written for) "label" and version X, where X >= compversion, it will know what features are mandatory and which are optional (new optional feature of a later version it won't know about, but it also won't support those). Therefore it can request those optional features that it supports and wants. (your points 'a', above). d. The server sends a final handshake where it tells the client with which features it will proceed (this is necessary as the server might DENY requested optional features, because it is possible that the current version of the server doesn't support those anymore; which doesn't make it incompatible with the viewer). Thus: TO client <-- NETWORK label1 version1 compversion1 [label2 version2 compversion2 ...] >From client --> PROT REQ label1 versionX (where compversion1 <= versionX <= version) TO client <-- PROT SET label1 versionX -- Carlo Wood From suzyque@gmail.com Mon Dec 7 15:40:48 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF2C3A69B8 for ; Mon, 7 Dec 2009 15:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh-BXEQXzg3v for ; Mon, 7 Dec 2009 15:40:47 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id C566B3A69AA for ; Mon, 7 Dec 2009 15:40:46 -0800 (PST) Received: by ewy3 with SMTP id 3so158965ewy.13 for ; Mon, 07 Dec 2009 15:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=MIP3iYXMKQWeIYV8xMFkOTHP2eVW5sajpv0RNXjlsxY=; b=u5fB/JVfeYSEQ4WWY+3B2H0vmNx2c2z+SmN1+HIGGb3V+68qP3NAZeZaaGCuU4z6AY A4Tb6rSVSJ3cD42HVa4i6pCR9RsvN8Q7jm4VLMDv1Eex/DWSRH3wmj7Cz1BomnETD+JT yH9P3fNuIt5TMJUROVOejGromzz3Eeam5/c5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=mJWAaF68Zrcwys9Bf0FEO10lgZZ3YaN4aP2/mKx3od4fFPvxy/FQ04C+vkHudW4Xtx yUQl8Dlwc9kzu3iqr+k0kfUtFrEwFdfip06nifAkfnttM5gW2MZ9ZDXQ7k9Q7NNbYK6S kDrXfxFBlCKah31GfqEucZcv0mQPeJSxndp2E= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.216.85.197 with SMTP id u47mr1088357wee.133.1260229230859; Mon, 07 Dec 2009 15:40:30 -0800 (PST) In-Reply-To: <20091207195825.GA23549@alinoe.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> <20091207195825.GA23549@alinoe.com> Date: Mon, 7 Dec 2009 17:40:30 -0600 X-Google-Sender-Auth: ed6e092ab42d9300 Message-ID: <2bd5b7f10912071540x6f1d797dw9941ace39dcb4b5a@mail.gmail.com> From: Suzy Deffeyes To: Carlo Wood Content-Type: multipart/alternative; boundary=0016e6d7ef62a41ff2047a2bfbd5 Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 23:40:48 -0000 --0016e6d7ef62a41ff2047a2bfbd5 Content-Type: text/plain; charset=ISO-8859-1 > > * In the latter case (the service not knowning about it) the viewer > needs to fall back to the old style map on opensim and to a hardcoded > S3 url on Second Life (which DOES support this capability, but just > doesn't know about the "capability" url itself). > > * Once Linden Lab (or any other grid that will implement the same > way that map works) stops supporting the "old style map", there > is no way to tell the client explicit that THIS "feature" (the > new way of how map works) is now mandatory, other than the > existing method of requiring a minimal *viewer* version... which > of course only works for the few viewers that are supported this > way and which is a very crude way to state that one feature is > now mandatory (bound to fail once there are lots of features > like this to be negotiated). > So in the map tile case you mention, if the viewer gets a cap to the new way of fetching tiles, it wouldn't try to do the old way. In this particular case, it seems like getting a cap for http fetch of map tiles deprecates client use of the old mechanism. "Mandatory" is something that should be dictated by a VWRAP spec version number. So in version 1.0 the map capability is not mandatory, and when we rev the version to 1.1, we might decide to make it mandatory. A viewer supporting version 1.1 of the spec could reliably ditch the old code. One thing I do ponder that might be related is how do I specify/decide that I do *not* want to trust a specific packet type from the region. For instance, if I get a cap for inventory operations from my agent domain, then maybe I don't want to trust UDP packets related to Inventory that I get from Joe's Prim Ripper region. Will it always be obvious what the desired behavior in the viewer is? In the map tile example, should I blow off any map tile packets i get from a region that also claims to support the map tile HTTP cap? Suzy Deffeyes/Pixel Gausman IBM --0016e6d7ef62a41ff2047a2bfbd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

* In the latter case (the service not knowning about it) the viewer
=A0needs to fall back to the old style map on opensim and to a hardcoded =A0S3 url on Second Life (which DOES support this capability, but just
=A0doesn't know about the "capability" url itself).

* Once Linden Lab (or any other grid that will implement the same
=A0way that map works) stops supporting the "old style map", the= re
=A0is no way to tell the client explicit that THIS "feature" (th= e
=A0new way of how map works) is now mandatory, other than the
=A0existing method of requiring a minimal *viewer* version... which
=A0of course only works for the few viewers that are supported this
=A0way and which is a very crude way to state that one feature is
=A0now mandatory (bound to fail once there are lots of features
=A0like this to be negotiated).

So in the map til= e case you mention, if the viewer gets a cap to the new way of fetching til= es, it wouldn't try to do the old way.=A0=A0 In this particular case, i= t seems like getting a cap for http fetch of map tiles deprecates client us= e of the old mechanism.

"Mandatory" is something that should be dictated by a VWRAP s= pec version number. So in version 1.0 the map capability is not mandatory, = and when we rev the version to 1.1, we might decide to make it mandatory. A= viewer supporting version 1.1 of the spec could reliably ditch the old cod= e.

One thing I do ponder that might be related is how do I specify/decide = that I do *not* want to trust a specific packet type from the region. For i= nstance, if I get a cap for inventory operations from my agent domain, then= maybe I don't want to trust UDP packets related to Inventory that I ge= t from Joe's Prim Ripper region.=A0 Will it always be obvious what the = desired behavior in the viewer is?=A0 In the map tile example, should I blo= w off any map tile packets i get from a region that also claims to support = the map tile HTTP cap?

Suzy Deffeyes/Pixel Gausman
IBM

--0016e6d7ef62a41ff2047a2bfbd5-- From carlo@alinoe.com Tue Dec 8 06:01:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66053A63D3 for ; Tue, 8 Dec 2009 06:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c77EuGyJ7wCV for ; Tue, 8 Dec 2009 06:01:12 -0800 (PST) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 5DB003A67A7 for ; Tue, 8 Dec 2009 06:01:11 -0800 (PST) Received: from edge04.upc.biz ([192.168.13.239]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091208140059.MVRG5725.viefep19-int.chello.at@edge04.upc.biz>; Tue, 8 Dec 2009 15:00:59 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id Ee0w1d0Cu0FlQed04e0xMz; Tue, 08 Dec 2009 15:00:59 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1NI0ZG-0001dB-IB; Tue, 08 Dec 2009 14:57:30 +0100 Date: Tue, 8 Dec 2009 14:57:30 +0100 From: Carlo Wood To: Suzy Deffeyes Message-ID: <20091208135730.GA4384@alinoe.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> <20091207195825.GA23549@alinoe.com> <2bd5b7f10912071540x6f1d797dw9941ace39dcb4b5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2bd5b7f10912071540x6f1d797dw9941ace39dcb4b5a@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 14:01:14 -0000 On Mon, Dec 07, 2009 at 05:40:30PM -0600, Suzy Deffeyes wrote: > > * In the latter case (the service not knowning about it) the viewer > needs to fall back to the old style map on opensim and to a hardcoded > S3 url on Second Life (which DOES support this capability, but just > doesn't know about the "capability" url itself). > > * Once Linden Lab (or any other grid that will implement the same > way that map works) stops supporting the "old style map", there > is no way to tell the client explicit that THIS "feature" (the > new way of how map works) is now mandatory, other than the > existing method of requiring a minimal *viewer* version... which > of course only works for the few viewers that are supported this > way and which is a very crude way to state that one feature is > now mandatory (bound to fail once there are lots of features > like this to be negotiated). > > > So in the map tile case you mention, if the viewer gets a cap to the new way of > fetching tiles, it wouldn't try to do the old way. Well, if it DOES get a cap, then clearly the service DOES know about the feature, so there is little need for the old style map. > In this particular case, > it seems like getting a cap for http fetch of map tiles deprecates client use > of the old mechanism. Yup. The problem that I tried to demonstrate that needs protocol/feature negotiation is for the case that the server does NOT return a cap. Wouldn't it an ideal world if in the end we'll have One Big Virual World ;) (rethorical question). But, one world or not (and certainly in the case where we have many different worlds) in the end we will have many different branches of servers. Server implementations written by different people, with different goals and ideas. At the client side the same thing will happen. Right now we ONLY have six or so separately maintained viewers; that number will grow a lot in the future up till the point where it is unpractical to maintain communication between client and server coders. If we all can convince ourselves that the standard that we will produce here is THE BEST-- and does not need ANY extensions or extra features, then surely we will decide that what we make here is the Best For Everyone, and Nobody Needs More. However, we are not the (only) server developers of the future, and I predict that there will be a growing number of server developers in the future that WILL feel the need for some new, till then unsupported feature. What is going to happen is that there WILL be a growing set of "features" on top of the VWRAP standard, and no controlled way to communicate all those features to the viewer developers... To make a long story short, it will become a mess. Soon you will only really be able to connect to server type "opensim" if you use their viewer; and only connect to Second Life if you use Linden Lab's viewer. The viewer coders will get frustrated about that, because they want to allow their users to connect whereever. So, they need to make their viewer adjust to the protocol as function of the server type that they connect to. At first, it would be sufficient to add some kludge to detect the major grids (as it works for "their own" viewer), but the growing number of servers and features will make a nightmare of this. Server version detection will be needed, and then the viewer coders will need to start to keep track of which versions of each server-type support what features. The methods used to determine if some feature is optional and whether or not a viewer can or want to use it will also be random (everyone implementing their own way). Some server developers will only support a few viewers and keep a list of versions of those viewers and then "negotiate" the features silently by assuming that viewer MyOwnViewer version 4.35 is compatible and has features A,E,J,M,N,X and Z, while FurryViewer version 1.11 is not compatible but 1.12 is but only supports features A,E,X and Z. Now LittleViewer can't connect at all (except for using the base VWRAP protocol) except by spoofing it's version and saying it is really FurryViewer, however LittleViewer's coder didn't really want to add feature X, rather wanted just to support feature F... Buttom line, this isn't about ONE application (a server) with a compatible viewer (client) that is controlled and maintained by the same people as the server. This is about a large network of servers and clients maintained and developed dynamically by many different groups and we DO NEED TO SUPPORT protocol evolution in order to avoid a complete future mess. If anyone doesn't believe that (or thinks that we can do this with just caps and the other methods already proposed in OGP) then I beg you to add this anyway: if no features are added then we're talking about three or four small, standard messages (two each direction) for each client-server connection, and no harm done. If anyone doesn't WANT this, because they don't want to see the protocol evolve, because a *standard* means that everyone uses the same, and therefore building in ways to add random features would only invite people to make viewers incompatible; then please reconsider. I strongly believe that not adding support will not stop people. Besides, it isn't bad if the protocol changes over time at all imho; look at it as evolution: support for the best features will be added to all viewers and servers, other features won't make it and die again. As long as it is crystal clear who supports what, and the documentation of each and every feature can easily be found back on the web, then I think we only gained. -- Carlo Wood From morgaine.dinova@googlemail.com Tue Dec 8 22:13:16 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122D73A6986 for ; Tue, 8 Dec 2009 22:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HucEzJozzITR for ; Tue, 8 Dec 2009 22:13:14 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 854E03A6ABA for ; Tue, 8 Dec 2009 22:13:13 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so848258eyd.51 for ; Tue, 08 Dec 2009 22:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=tPCMFZ23CWXVTWyftW3DJeg8bTKn3yMm/nZgshKxJbw=; b=LATfaTlSlbmFDYgwODmBasUH6H1/Bw91UuzahkzGVyhp+lYqe0BmNFd6Pb7TIpbvRr xz1o2ZQeEepzWifuEat2OjmQVJoiasSKgNnrmLUrJURyWPNfVH4wl8SOMILncmccO6C/ Ts4enGYHycux3rgZPRaRdrPQ6sEUxq9cxCZ8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wQF6YZ726904NKkDuv6JhXATj33WAATNLeiV9/WM3ZTscDn0epdL0ccP1HXnzqBgPD FK6uf3UMafrY/go729t3bEPHGjUOGpFELKc6M1SAs8j/k23q8VfB3qreI61aj2i2zhGW 21IJyGn1KmbGqhjMQrZRbayqab7u5BF/hP2k0= MIME-Version: 1.0 Received: by 10.216.87.206 with SMTP id y56mr3184573wee.207.1260339179807; Tue, 08 Dec 2009 22:12:59 -0800 (PST) In-Reply-To: <2bd5b7f10912071540x6f1d797dw9941ace39dcb4b5a@mail.gmail.com> References: <4B1B785A.9000602@cox.net> <20091207001703.GA26539@alinoe.com> <20091207195825.GA23549@alinoe.com> <2bd5b7f10912071540x6f1d797dw9941ace39dcb4b5a@mail.gmail.com> Date: Wed, 9 Dec 2009 06:12:59 +0000 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6d976821be3a8047a4595e8 Subject: Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 06:13:16 -0000 --0016e6d976821be3a8047a4595e8 Content-Type: text/plain; charset=ISO-8859-1 VWRAP version numbers should change only when the base protocol itself is incompatible between versions, and never just because a particular feature is or is not supported by the client or by the server. There will be hundreds or thousands of features in the future of VWRAP, an ever-evolving set of them, and the protocol needs to be generic enough to support such diversity. Protocol version numbers are the wrong place for selecting features or feature sets. The map tile access mechanism is definitely not the kind of thing that VWRAP version numbers would be expected to select. Such a choice needs to be dynamic because it's not fixed for the life of the session. Maps are determined by region policy or virtual world policy, and are not in any way related to the session that commences with authenticating with the agent domain. The topological layout of regions or region domains is a matter for each virtual world to control, while the visual data for each tile is a matter for each region or region domain to determine. Capabilities for map retrieval will have to be obtained accordingly, in a dynamic manner, because the mechanism that is required will vary as one travels around. There will probably be several mechanisms in common use. It should be noted that VWRAP users will be visiting many different worlds, each one with its own feature set, so non-uniformity should be expected to be the norm. Even our first two sample points of SL and OSgrid already illustrate lack of uniformity in numerous features, and we can expect this to continue and to expand. It's a situation that we must embrace through designing a protocol that is inherently extensible, and in which features are selected dynamically. Morgaine. ========================================== On Mon, Dec 7, 2009 at 11:40 PM, Suzy Deffeyes wrote: > > >> * In the latter case (the service not knowning about it) the viewer >> needs to fall back to the old style map on opensim and to a hardcoded >> S3 url on Second Life (which DOES support this capability, but just >> doesn't know about the "capability" url itself). >> >> * Once Linden Lab (or any other grid that will implement the same >> way that map works) stops supporting the "old style map", there >> is no way to tell the client explicit that THIS "feature" (the >> new way of how map works) is now mandatory, other than the >> existing method of requiring a minimal *viewer* version... which >> of course only works for the few viewers that are supported this >> way and which is a very crude way to state that one feature is >> now mandatory (bound to fail once there are lots of features >> like this to be negotiated). >> > > So in the map tile case you mention, if the viewer gets a cap to the new > way of fetching tiles, it wouldn't try to do the old way. In this > particular case, it seems like getting a cap for http fetch of map tiles > deprecates client use of the old mechanism. > > "Mandatory" is something that should be dictated by a VWRAP spec version > number. So in version 1.0 the map capability is not mandatory, and when we > rev the version to 1.1, we might decide to make it mandatory. A viewer > supporting version 1.1 of the spec could reliably ditch the old code. > > One thing I do ponder that might be related is how do I specify/decide that > I do *not* want to trust a specific packet type from the region. For > instance, if I get a cap for inventory operations from my agent domain, then > maybe I don't want to trust UDP packets related to Inventory that I get from > Joe's Prim Ripper region. Will it always be obvious what the desired > behavior in the viewer is? In the map tile example, should I blow off any > map tile packets i get from a region that also claims to support the map > tile HTTP cap? > > Suzy Deffeyes/Pixel Gausman > IBM > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e6d976821be3a8047a4595e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable VWRAP version numbers should change only when the base protocol itself is i= ncompatible between versions, and never just because a particular feature i= s or is not supported by the client or by the server.=A0 There will be hund= reds or thousands of features in the future of VWRAP, an ever-evolving set = of them, and the protocol needs to be generic enough to support such divers= ity.=A0 Protocol version numbers are the wrong place for selecting features= or feature sets.

The map tile access mechanism is definitely not the kind of thing that = VWRAP version numbers would be expected to select.=A0 Such a choice needs t= o be dynamic because it's not fixed for the life of the session.
Maps are determined by region policy or virtual world policy, and are not i= n any way related to the session that commences with authenticating with th= e agent domain.=A0 The topological layout of regions or region domains is a= matter for each virtual world to control, while the visual data for each t= ile is a matter for each region or region domain to determine.=A0 Capabilit= ies for map retrieval will have to be obtained accordingly, in a dynamic ma= nner, because the mechanism that is required will vary as one travels aroun= d.=A0 There will probably be several mechanisms in common use.

It should be noted that VWRAP users will be visiting many different wor= lds, each one with its own feature set, so non-uniformity should be expecte= d to be the norm.=A0 Even our first two sample points of SL and OSgrid alre= ady illustrate lack of uniformity in numerous features, and we can expect t= his to continue and to expand.=A0 It's a situation that we must embrace= through designing a protocol that is inherently extensible, and in which f= eatures are selected dynamically.

Morgaine.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

On Mon, Dec 7, 2009 at= 11:40 PM, Suzy Deffeyes <suzyq@pobox.com> wrote:

* In the latter case (the service not knowning about it) the viewer
=A0needs to fall back to the old style map on opensim and to a hardcoded =A0S3 url on Second Life (which DOES support this capability, but just
=A0doesn't know about the "capability" url itself).

* Once Linden Lab (or any other grid that will implement the same
=A0way that map works) stops supporting the "old style map", the= re
=A0is no way to tell the client explicit that THIS "feature" (th= e
=A0new way of how map works) is now mandatory, other than the
=A0existing method of requiring a minimal *viewer* version... which
=A0of course only works for the few viewers that are supported this
=A0way and which is a very crude way to state that one feature is
=A0now mandatory (bound to fail once there are lots of features
=A0like this to be negotiated).

So in the m= ap tile case you mention, if the viewer gets a cap to the new way of fetchi= ng tiles, it wouldn't try to do the old way.=A0=A0 In this particular c= ase, it seems like getting a cap for http fetch of map tiles deprecates cli= ent use of the old mechanism.

"Mandatory" is something that should be dictated by a VWRAP s= pec version number. So in version 1.0 the map capability is not mandatory, = and when we rev the version to 1.1, we might decide to make it mandatory. A= viewer supporting version 1.1 of the spec could reliably ditch the old cod= e.

One thing I do ponder that might be related is how do I specify/decide = that I do *not* want to trust a specific packet type from the region. For i= nstance, if I get a cap for inventory operations from my agent domain, then= maybe I don't want to trust UDP packets related to Inventory that I ge= t from Joe's Prim Ripper region.=A0 Will it always be obvious what the = desired behavior in the viewer is?=A0 In the map tile example, should I blo= w off any map tile packets i get from a region that also claims to support = the map tile HTTP cap?

Suzy Deffeyes/Pixel Gausman
IBM

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0016e6d976821be3a8047a4595e8-- From dahliatrimble@gmail.com Wed Dec 9 00:27:32 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295D73A65A5 for ; Wed, 9 Dec 2009 00:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTmn-Fw5f++d for ; Wed, 9 Dec 2009 00:27:30 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id C44E03A68F1 for ; Wed, 9 Dec 2009 00:27:30 -0800 (PST) Received: by pzk6 with SMTP id 6so5332373pzk.29 for ; Wed, 09 Dec 2009 00:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=r3s000AD2Te2PRBFyPjsMmWvq6yL/8BPp7lOfV+6hf4=; b=r5+3w1N/MGm0kWkiLwwmxs623XTHPZTWLgaif5fH3LLXrxuJ6odezPGObfwI34vwZY he12oM9BinWauMkZqv1epCjwhN6seGxrMG77cesXie2QRRRBzOwWXYhzbrtFVRdgC2Ay VLhnKmI8nx+rk7fZEnMJQfd6A6lhtmjgDZH2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JI94Xg5BY7M6ttTXJlcMTQps1O72SjajGGTEyc3jvItEz1OktnQ+uS+b0Ab1zsRw8G 7pVVM2w3qPD1X3b/eo+YDL+FvbILqZRipkPtuipvjYg0wRsv/BlMd9vu34n4I1u1ACl1 AW4EujWCVIjxuZesmFdM4nT/BHkfC/RQ5qdLA= MIME-Version: 1.0 Received: by 10.143.24.42 with SMTP id b42mr1004524wfj.237.1260347237774; Wed, 09 Dec 2009 00:27:17 -0800 (PST) In-Reply-To: <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> Date: Wed, 9 Dec 2009 00:27:17 -0800 Message-ID: From: Dahlia Trimble To: "sldev@lists.secondlife.com" Content-Type: multipart/alternative; boundary=001636e1f7ab66b852047a477563 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] [sldev] Snowglobe on OpenSim grids X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 08:27:32 -0000 --001636e1f7ab66b852047a477563 Content-Type: text/plain; charset=ISO-8859-1 Along the same lines of the hard coded map URL, there's one other URL that I'm aware of that appears to be hard coded: the search pages. Could similar logic that's been discussed so far for the map be applicable for search as well? Or is there a better solution? -Dahlia On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes wrote: > I originally added the map tile cap to my Snowglobe 1.3 wishlist > because currently when http texture fetches are enabled, OpenSim users > get completely wrong map tiles. That's just rude for them. I wanted > to fix it for existing OpenSim grids, so they could implement serving > the correct map tiles via http. > > I wasn't thinking of it as vwrap related, although it does illustrate > the interesting dance from udp to http, and some of the issues with > that. > > Can we make a simple fix for OpenSim now that will still work with the > existing Linden grid, irrespective of vwrap? > > Suzy/Pixel > > Sent from my iPhone > > On Dec 6, 2009, at 6:33 PM, Carlo Wood wrote: > > > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: > >> If the code defaults to the existing hardcoded amazon behavior if a > >> cap to map tiles is not returned, then it doesn't require a LL > >> protocol change. > > > > There will be a time that not all OTHER implementations (ie opensim) > > have implemented this; in which case the cap will fail. > > > > In that case we want to fall back to the OLD way maps worked, > > because that is what works on opensim, at least - on opensim. > > > > Hence, this would require "detection" of on which network > > we are, and then adjust the "protocol" as required... > > > > I just wrote a long post about this horror (believe, it will > > happen again and again and again and the list of this type > > of things will only get LONGER and LONGER!). > > > > What we need, from the very start, is a good protocol > > negotiation sheme added to VWRAP (the new name for OGP). > > > > The protocol negotion sheme that I have proposed would > > make it clear what the base protocol is (the mandatory > > features so to say), as each server implementation gets > > it's own label (ie, LindenLab and OpenSim (as well as > > version numbers of course)). Then you could indeed say: > > > > Hey, opensim doesn't offer the feature "NewMap", so > > we use the old style map. And, hey, LindenLab doesn't > > offer the feature "NewMapURL", so we just use the S3 > > url as fall back (for the mandatory "NewMap" feature). > > > > Also, "NewMap" is really optional at the moment (the > > 1.23 viewers don't use it)... If the protocol negotiation > > had already been in place, then LL would have added > > an optional "NewMap" feature, with documentation, at > > the same time that it became available. The 1.23 viewer > > would not have known what it was and wouldn't use it, > > snowglobe would and would use it. THEN, on opensim, > > snowglobe would see that there isn't an optional > > "NewMap" feature and would NOT use the new map style. > > > > This demonstrates the power, and need, for protocol > > negotiation. > > > > At some later date, LL would add support for the new > > map also to the official viewers and make the feature > > mandatory (so that everyone with a client that doesn't > > support it has to upgrade). With the protocol negotiation > > that I proposed, the whole "NewMap" option would disappear > > from the actual negotiation (the documentation would > > still be there though, on the net ;), as if it had > > been a part of the protocol like everything else > > mandatory (ie, support for teleporting). > > > > -- > > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > --001636e1f7ab66b852047a477563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Along the same lines of the hard coded map URL, there's one other URL t= hat I'm aware of that appears to be hard coded: the search pages. Could= similar logic that's been discussed so far for the map be applicable f= or search as well? Or is there a better solution?

-Dahlia

On Tue, Dec 8, 200= 9 at 5:23 AM, Suzy Deffeyes <suzyque@gmail.com> wrote:

I originally added the map tile cap to my Snowglobe 1.3 wishlist
because currently when http texture fetches are enabled, OpenSim users
get completely wrong map tiles. That's just rude for them. =A0I wanted<= br> to fix it for existing OpenSim grids, so they could implement serving
the correct map tiles via http.

I wasn't thinking of it as vwrap related, although it does illustrate the interesting dance from udp to http, and some of the issues with
that.

Can we make a simple fix for OpenSim now that will still work with the
existing Linden grid, irrespective of vwrap?

Suzy/Pixel

Sent from my iPhone

On Dec 6, 2009, at 6:33 PM, Carlo W= ood <carlo@alinoe.com> wrote:=

> On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote:
>> If the code defaults to the existing hardcoded amazon behavior if = a
>> cap to map tiles is not returned, then it doesn't require a LL=
>> protocol change.
>
> There will be a time that not all OTHER implementations (ie opensim) > have implemented this; in which case the cap will fail.
>
> In that case we want to fall back to the OLD way maps worked,
> because that is what works on opensim, at least - on opensim.
>
> Hence, this would require "detection" of on which network > we are, and then adjust the "protocol" as required...
>
> I just wrote a long post about this horror (believe, it will
> happen again and again and again and the list of this type
> of things will only get LONGER and LONGER!).
>
> What we need, from the very start, is a good protocol
> negotiation sheme added to VWRAP (the new name for OGP).
>
> The protocol negotion sheme that I have proposed would
> make it clear what the base protocol is (the mandatory
> features so to say), as each server implementation gets
> it's own label (ie, LindenLab and OpenSim (as well as
> version numbers of course)). Then you could indeed say:
>
> Hey, opensim doesn't offer the feature "NewMap", so
> we use the old style map. And, hey, LindenLab doesn't
> offer the feature "NewMapURL", so we just use the S3
> url as fall back (for the mandatory "NewMap" feature).
>
> Also, "NewMap" is really optional at the moment (the
> 1.23 viewers don't use it)... If the protocol negotiation
> had already been in place, then LL would have added
> an optional "NewMap" feature, with documentation, at
> the same time that it became available. The 1.23 viewer
> would not have known what it was and wouldn't use it,
> snowglobe would and would use it. THEN, on opensim,
> snowglobe would see that there isn't an optional
> "NewMap" feature and would NOT use the new map style.
>
> This demonstrates the power, and need, for protocol
> negotiation.
>
> At some later date, LL would add support for the new
> map also to the official viewers and make the feature
> mandatory (so that everyone with a client that doesn't
> support it has to upgrade). With the protocol negotiation
> that I proposed, the whole "NewMap" option would disappear > from the actual negotiation (the documentation would
> still be there though, on the net ;), as if it had
> been a part of the protocol like everything else
> mandatory (ie, support for teleporting).
>
> --
> Carlo Wood <carlo@alinoe.com>
_______________________________________________

Policies and (un)subscribe in= formation available here:
http://= wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privile= ges

--001636e1f7ab66b852047a477563-- From dwl@us.ibm.com Wed Dec 9 07:08:45 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6D73A6897; Wed, 9 Dec 2009 07:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.856 X-Spam-Level: X-Spam-Status: No, score=-4.856 tagged_above=-999 required=5 tests=[AWL=1.742, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX+RNbar3GsA; Wed, 9 Dec 2009 07:08:44 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id DAF043A67BE; Wed, 9 Dec 2009 07:08:43 -0800 (PST) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB9F3Wch013074; Wed, 9 Dec 2009 10:03:32 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB9F8PrM091524; Wed, 9 Dec 2009 10:08:25 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB9F8LMh026627; Wed, 9 Dec 2009 13:08:21 -0200 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB9F8INJ026346; Wed, 9 Dec 2009 13:08:19 -0200 In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> To: Dahlia Trimble MIME-Version: 1.0 X-KeepSent: C0E5EA8C:AE3F5B5D-85257687:00531143; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Wed, 9 Dec 2009 10:08:17 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/09/2009 10:08:18, Serialize complete at 12/09/2009 10:08:18 Content-Type: multipart/alternative; boundary="=_alternative 0053286B85257687_=" Cc: "sldev@lists.secondlife.com" , ogpx-bounces@ietf.org, "ogpx@ietf.org" Subject: Re: [ogpx] [sldev] Snowglobe on OpenSim grids X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:08:45 -0000 This is a multipart message in MIME format. --=_alternative 0053286B85257687_= Content-Type: text/plain; charset="US-ASCII" I honestly can't imagine why we wouldn't. Hard coded singletons are totally silly in a world that's growing towards interoperability. - David ~ Zha Dahlia Trimble Sent by: ogpx-bounces@ietf.org 12/09/2009 03:27 AM To "sldev@lists.secondlife.com" cc "ogpx@ietf.org" Subject Re: [ogpx] [sldev] Snowglobe on OpenSim grids Along the same lines of the hard coded map URL, there's one other URL that I'm aware of that appears to be hard coded: the search pages. Could similar logic that's been discussed so far for the map be applicable for search as well? Or is there a better solution? -Dahlia On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes wrote: I originally added the map tile cap to my Snowglobe 1.3 wishlist because currently when http texture fetches are enabled, OpenSim users get completely wrong map tiles. That's just rude for them. I wanted to fix it for existing OpenSim grids, so they could implement serving the correct map tiles via http. I wasn't thinking of it as vwrap related, although it does illustrate the interesting dance from udp to http, and some of the issues with that. Can we make a simple fix for OpenSim now that will still work with the existing Linden grid, irrespective of vwrap? Suzy/Pixel Sent from my iPhone On Dec 6, 2009, at 6:33 PM, Carlo Wood wrote: > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: >> If the code defaults to the existing hardcoded amazon behavior if a >> cap to map tiles is not returned, then it doesn't require a LL >> protocol change. > > There will be a time that not all OTHER implementations (ie opensim) > have implemented this; in which case the cap will fail. > > In that case we want to fall back to the OLD way maps worked, > because that is what works on opensim, at least - on opensim. > > Hence, this would require "detection" of on which network > we are, and then adjust the "protocol" as required... > > I just wrote a long post about this horror (believe, it will > happen again and again and again and the list of this type > of things will only get LONGER and LONGER!). > > What we need, from the very start, is a good protocol > negotiation sheme added to VWRAP (the new name for OGP). > > The protocol negotion sheme that I have proposed would > make it clear what the base protocol is (the mandatory > features so to say), as each server implementation gets > it's own label (ie, LindenLab and OpenSim (as well as > version numbers of course)). Then you could indeed say: > > Hey, opensim doesn't offer the feature "NewMap", so > we use the old style map. And, hey, LindenLab doesn't > offer the feature "NewMapURL", so we just use the S3 > url as fall back (for the mandatory "NewMap" feature). > > Also, "NewMap" is really optional at the moment (the > 1.23 viewers don't use it)... If the protocol negotiation > had already been in place, then LL would have added > an optional "NewMap" feature, with documentation, at > the same time that it became available. The 1.23 viewer > would not have known what it was and wouldn't use it, > snowglobe would and would use it. THEN, on opensim, > snowglobe would see that there isn't an optional > "NewMap" feature and would NOT use the new map style. > > This demonstrates the power, and need, for protocol > negotiation. > > At some later date, LL would add support for the new > map also to the official viewers and make the feature > mandatory (so that everyone with a client that doesn't > support it has to upgrade). With the protocol negotiation > that I proposed, the whole "NewMap" option would disappear > from the actual negotiation (the documentation would > still be there though, on the net ;), as if it had > been a part of the protocol like everything else > mandatory (ie, support for teleporting). > > -- > Carlo Wood _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0053286B85257687_= Content-Type: text/html; charset="US-ASCII"
I honestly can't imagine why we wouldn't. Hard coded singletons are totally silly in a world that's growing towards interoperability.
- David
~ Zha

Dahlia Trimble <dahliatrimble@gmail.com>
Sent by: ogpx-bounces@ietf.org

12/09/2009 03:27 AM

To	"sldev@lists.secondlife.com" <sldev@lists.secondlife.com>
cc	"ogpx@ietf.org" <ogpx@ietf.org>
Subject	Re: [ogpx] [sldev] Snowglobe on OpenSim grids

Along the same lines of the hard coded map URL, there's one other URL that I'm aware of that appears to be hard coded: the search pages. Could similar logic that's been discussed so far for the map be applicable for search as well? Or is there a better solution?

-Dahlia

On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes <suzyque@gmail.com> wrote:
I originally added the map tile cap to my Snowglobe 1.3 wishlist
because currently when http texture fetches are enabled, OpenSim users
get completely wrong map tiles. That's just rude for them. I wanted
to fix it for existing OpenSim grids, so they could implement serving
the correct map tiles via http.

I wasn't thinking of it as vwrap related, although it does illustrate
the interesting dance from udp to http, and some of the issues with
that.

Can we make a simple fix for OpenSim now that will still work with the
existing Linden grid, irrespective of vwrap?

Suzy/Pixel

Sent from my iPhone

On Dec 6, 2009, at 6:33 PM, Carlo Wood <carlo@alinoe.com> wrote:

> On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote:
>> If the code defaults to the existing hardcoded amazon behavior if a
>> cap to map tiles is not returned, then it doesn't require a LL
>> protocol change.
>
> There will be a time that not all OTHER implementations (ie opensim)
> have implemented this; in which case the cap will fail.
>
> In that case we want to fall back to the OLD way maps worked,
> because that is what works on opensim, at least - on opensim.
>
> Hence, this would require "detection" of on which network
> we are, and then adjust the "protocol" as required...
>
> I just wrote a long post about this horror (believe, it will
> happen again and again and again and the list of this type
> of things will only get LONGER and LONGER!).
>
> What we need, from the very start, is a good protocol
> negotiation sheme added to VWRAP (the new name for OGP).
>
> The protocol negotion sheme that I have proposed would
> make it clear what the base protocol is (the mandatory
> features so to say), as each server implementation gets
> it's own label (ie, LindenLab and OpenSim (as well as
> version numbers of course)). Then you could indeed say:
>
> Hey, opensim doesn't offer the feature "NewMap", so
> we use the old style map. And, hey, LindenLab doesn't
> offer the feature "NewMapURL", so we just use the S3
> url as fall back (for the mandatory "NewMap" feature).
>
> Also, "NewMap" is really optional at the moment (the
> 1.23 viewers don't use it)... If the protocol negotiation
> had already been in place, then LL would have added
> an optional "NewMap" feature, with documentation, at
> the same time that it became available. The 1.23 viewer
> would not have known what it was and wouldn't use it,
> snowglobe would and would use it. THEN, on opensim,
> snowglobe would see that there isn't an optional
> "NewMap" feature and would NOT use the new map style.
>
> This demonstrates the power, and need, for protocol
> negotiation.
>
> At some later date, LL would add support for the new
> map also to the official viewers and make the feature
> mandatory (so that everyone with a client that doesn't
> support it has to upgrade). With the protocol negotiation
> that I proposed, the whole "NewMap" option would disappear
> from the actual negotiation (the documentation would
> still be there though, on the net ;), as if it had
> been a part of the protocol like everything else
> mandatory (ie, support for teleporting).
>
> --
> Carlo Wood <carlo@alinoe.com>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________ ogpx mailing list ogpx@ietf.orghttps://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 0053286B85257687_=--