Re: [mmox] One more time: The LESS model vs the Generic Client model
Kajikawa Jeremy <belxjander@gmail.com> Mon, 16 March 2009 14:13 UTC
Return-Path: <belxjander@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2186228C199 for <mmox@core3.amsl.com>; Mon, 16 Mar 2009 07:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.525
X-Spam-Level:
X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 NTe503Gy8Tpb for <mmox@core3.amsl.com>; Mon, 16 Mar 2009 07:13:49 -0700 (PDT)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 87E8028C19B for <mmox@ietf.org>; Mon, 16 Mar 2009 07:13:49 -0700 (PDT)
Received: by yx-out-2324.google.com with SMTP id 8so1907434yxm.49 for <mmox@ietf.org>; Mon, 16 Mar 2009 07:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=BcgSdHjPtNRkDj7kW3TXHMbPMWOB/BWbrMhvXgRBuBU=; b=pKeo3SaHMaYDj54pObef508AKYq+skMyZ8mn0RK3WdnzXYgUTUz74rdyDSH9+b0RHb Ahbp7q1Ms2COrVnahs6KbJDh0S/pKEnqKFNVO2rAcq+HRntJB2cLBOyEsPdWSUI876+k wYxGmL5DN128lGsIQVg2AgVGD4fCFZtcVEmJA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=o7WuU5F7ezPwe7B+N+4Z2S7EE1572ytjBQBV5O02wYFwYLoxK6jQh/2i1Iaf29+GXe NXWmREN486iskKOpL7o2SzbAFyhtLdZVaiicUDuLEjeLh4jSXBJCg2pPsOdSOf/Sp6zj dFQkCCSF6ZXL+MS2He3ty2hMlH5rVQZxWckCo=
Received: by 10.142.81.7 with SMTP id e7mr2175293wfb.106.1237212869386; Mon, 16 Mar 2009 07:14:29 -0700 (PDT)
Received: from ?10.2.1.3? (p3159-ipbfp201tottori.tottori.ocn.ne.jp [122.21.102.159]) by mx.google.com with ESMTPS id 28sm12050497wfd.25.2009.03.16.07.14.27 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 07:14:28 -0700 (PDT)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: Jon Watte <jwatte@gmail.com>
In-Reply-To: <49BDD5F1.5090303@gmail.com>
References: <e0b04bba0903120735s5311a922ybbc40a30433166a3@mail.gmail.com> <49B934B9.3080408@gmail.com> <49B940DF.8040009@lindenlab.com> <e0b04bba0903130451v2d33f9ebxfa3b337513bf286c@mail.gmail.com> <49BB0C46.8070809@gmail.com> <e0b04bba0903140305ocdbef86kcec140371dabf00b@mail.gmail.com> <49BC08DC.2010503@gmail.com> <e0b04bba0903150441y2b0037c7ne33a7ef6c883eb37@mail.gmail.com> <49BD6123.2080703@gmail.com> <e0b04bba0903151557u5312299ehe0a548f5790fb7a5@mail.gmail.com> <49BDD5F1.5090303@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-m2oTLA7wJa6mRMtaO+t7"
Date: Mon, 16 Mar 2009 23:14:25 +0900
Message-Id: <1237212865.23750.53.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.4
Cc: mmox@ietf.org
Subject: Re: [mmox] One more time: The LESS model vs the Generic Client model
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2009 14:13:51 -0000
Dont need to dictate the server environment... only need for any given server to provide means of an object being "representable" on a second server with "event forwarding" of whatever happens to one copy being propogated forward. the only issue becoming "tracking" the disparate objects.... Ive actually gone ahead and tried to model a mechanism for such things and have actually run into a quirk of the way a couple of MMO systems work. anything with a distinct backend database can run local event tracking and will be treated as a single-"server role"-entity serving a given MMO content. while a second system will need to provide or be provided some kind of secure(?) mechanism for a shared-object-key to be used in "update" messages. My own view of any object whether in 2D/3D or OOP environment, is along the lines of "X exists", lvalue=X::get(attr); / X::set(attr, lvalue); and the only things needing to be shared would be scripting being able to handle an "extern message" for "extern_send()" or "extern_recv()" event handling. do the disparate replications? of the object HAVE to be in perfect sync? doubt it, why bother? only when the object is statefull does it need sync, and then that would be arms to an octopus (object in DB with state-engine and representations are the tentacles). I am personally treating the "rendered space" as the user view, the "relational space" as mapped by the region/physics engine, "object scripting & storage"( DB + script servers). DB( object data ) this is "area" of the object itself SCRIPT( object event processing ) this is object specific programming SPATIAL( object mapping ) events are triggered through this relational mapping PHYSICS( object motion/opacity ) anything happening to one or more objects spatial and physics I see as being two halves of a whole (no spatial = no physics), RENDERED( object display for users ) I know I am describing pretty much a generic model of the servers already available regardless of server. right now I am seeing the problem as this... How are we going to have 1 or more services "share" spatial and physics mapping, the use case I have in mind is this... object X is being shown to N users across M "services"... X is originating from service M(0) and also displaying on M(P) M(Q) and M(R), M(P) M(Q) and M(R) need to propogate events back to M(O) and receive updates in state from M(O) but this runs into a heirarchy problem of concurrency. I see this as being described by JW, I also see the following use-case, object("something") is created by User("creatoid"), User("creatoid") sells User("Random.Joe") object("something"). User("creatoid") is normally on a private server but is using a store on a shared-space system and User("Random.Joe") is from a public service. Does the object he purchased transfer FROM "creatoid"s private server provision of storage and scripting? or does creatoid need to program for a "storage and scripting" service thats independant of both services ? In the above... I see "Creatoid" as creating on his home private system, and programming the object after transfer to a seperate service for storage & scripting before selling on the shared spaces. maybe Im being stupid, but I am considering the protocol we are developing as providing "event trigger" messages with some requiring "best effort" like UDP and others requiring "MUST HAPPEN" meaning it has to be heard for state. I personally think use of RHTTP for some things would work nicely, for others it will require some kind of custom server for showing an API to accept LESS, But in ALL shared-space areas... there will eventually need to be support for any system to either "proxy" their own client into an alternate service...(server expensive) or provide means for any of the "generic" clients which support both spaces to make a transition. Right now we need the former so the latter can be developed. But there is always going to be a "generic client", right now do we need to care about the clients so much? probably not, Do we have the mechanisms for later generic clients to work? doesn't matter as the generic clients WILL find a means to work I dont see any world specific client backing off if a central "client library" becomes available similar to how libpurple provides adium/pidgin and also how the "telepathy stack" supports the "empathy" client for IM/IRC/VoIP, Whats to stop "telepathy" having SecondLife or OLIVE or another "world protocol" being added to the stack with a 3D world browser as well? the "Web Browser" is now considered a "standard feature" as part of a computer being "Installed" from blank slate, it is now that ubiquitous, why block the same? or optionally, block being browsed by user-clients? Im still looking forward to when ALL the various services have cross-connects and I can walk/fly/run/swim and otherwise travel between systems without need of using a teleport of any kind. as for "mapping"... any world only needs to map itself to its own boundaries, just because you walk forwards through the portal to "zone" from one area to the next does not mean walking backward through the same portal will put you back where you came from... If I ever try to be a GM and RP this group... I would seriously through everyone here through a mental wringer since I would definitely portal people along with "shard" the landscape so that areas that are close are not and areas that are not close actually are.... I can map things that way for myself, but I dont actually expect anyone here to grok the map :) Jeremy On Sun, 2009-03-15 at 21:30 -0700, Jon Watte wrote: > Morgaine wrote: > > On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <jwatte@gmail.com > > <mailto:jwatte@gmail.com>> wrote: > > > > > > Actually, I have seen the Open Sim people propose and argue for > > the "generic client" concept. > > > > > > > > Generic clients are completely inevitable > > That is your opinion, but you seem to present it like scientific fact. > There are some generic clients, for some worlds. If I understand you > correctly, you believe that there will be one or more clients that will > actually connect to most virtual worlds in existence. Am I understanding > you correctly? > > I think that generic clients that connect to many different kinds of > virtual worlds are not only a bad idea. They are way too expensive > considering that they solve only a pretty trivial problem (the problem, > in the status quo, that you need to switch clients when switching > worlds). Note that generic clients do not give you the mash-up > capability of using objects that come from two separate worlds in a > common space. Only one of the two options of "dictate the server > execution environment" or "server <-> server interoperability" gives you > that (unless you're aware of some model I'm not, but are holding back). > That's a problem I think adds tremendous value, and moves the metaverse > substantially forward. > > > that they're already here in our midst > > If I understand you correctly: You believe that a client that can only > talk to Second Life derived virtual worlds is "generic"? That's what I'm > hearing. > Do you also believe that the Metaverse.net client is "generic," because > it can talk to all the difference virtual worlds built on the Metaverse > platform? > Do you believe that the OLIVE client is "generic" because it can talk to > all of the virtual worlds built on the OLIVE platform? > If you mean something else, please point me at concrete examples. > > > > > But we are talking about clients involved in interoperating worlds, > > not the total number of clients in existence. Since worlds of > > different types do not currently interoperate, talking about the > > clients they use doesn't seem very relevant. Looking at the > > I think it is very relevant! It's simple economics: > > Broad adoption of a standard only happens when it significantly improves > the status quo, such that the engineering necessary to adhere to the > standard costs less than the benefit of adhering to the standard. If the > status quo means that you can visit different worlds, and the adoption > of a standard means that you can visit different worlds, faster, but > otherwise changes nothing, then the value of that standard is the value > for the users in being able to switch between worlds faster. > > My argument is that that's pretty low value, and thus will not incite > broad adoption. My argument is also that if you're to build a generic > client that reaches even 50% of all the virtual worlds out there, you > have to either incorporate a large number of different protocols, OR you > have to convince a large number of virtual world vendors to re-do their > client/server communications stack to a common format. Both of those > alternatives have a very high cost associated with them. > > Note that I'm not talking about broad adoption among "Second Life Users" > or even "World of Warcraft Users" (a group 10x the size of the former) > -- I'm talking about adoption within governments, companies, > non-profits, churches, countries and everyone else who is currently > virtual world illiterate. Our job is to make sure that using virtual > worlds makes sense for those people; that it can transform the way they > live their lives and do their work for the better. > > > You can view this as client proliferation (they're all different) or > > as clients coallescing and tending towards a single generic client > > (they're all based on a similar model), but however you view it, both > > the genericity and the proliferation are here to stay. ;-) > > Let me see if I understand you correctly: > You believe that the Second Life model is actually superior, and will > prevail over all other virtual world models? > That's what the above sounds like you're saying to me, but I want to > make sure I understand you clearly. > In my view, nobody but the Second Life / OpenSim sphere is trending > towards a common generic client, and the reason that Second Life / > OpenSim are "trending" towards that direction is that they all started > out from the same place to begin with. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
- [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Jon Watte
- Re: [mmox] 3-world OGP interop scenario Meadhbh Hamrick (Infinity)
- Re: [mmox] 3-world OGP interop scenario Rob Lanphier
- Re: [mmox] 3-world OGP interop scenario Jon Watte
- Re: [mmox] 3-world OGP interop scenario Ann Otoole
- Re: [mmox] 3-world OGP interop scenario Meadhbh Hamrick (Infinity)
- Re: [mmox] 3-world OGP interop scenario Ann Otoole
- Re: [mmox] 3-world OGP interop scenario Mystical Demina
- Re: [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- Re: [mmox] 3-world OGP interop scenario Bill Humphries
- Re: [mmox] 3-world OGP interop scenario Meadhbh Hamrick (Infinity)
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- Re: [mmox] 3-world OGP interop scenario David W Levine
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- [mmox] My reading of draft-lentczner-ogp-base-00 Latha Serevi
- Re: [mmox] My reading of draft-lentczner-ogp-base… Meadhbh Hamrick (Infinity)
- Re: [mmox] 3-world OGP interop scenario Jon Watte
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- Re: [mmox] 3-world OGP interop scenario eh2th-mmox
- Re: [mmox] 3-world OGP interop scenario Mystical Demina
- Re: [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Jon Watte
- Re: [mmox] 3-world OGP interop scenario Ann Otoole
- Re: [mmox] 3-world OGP interop scenario eh2th-mmox
- [mmox] One more time: The LESS model vs the Gener… Jon Watte
- Re: [mmox] 3-world OGP interop scenario Mystical Demina
- Re: [mmox] One more time: The LESS model vs the G… Charles Krinke
- Re: [mmox] One more time: The LESS model vs the G… Kajikawa Jeremy
- Re: [mmox] One more time: The LESS model vs the G… Morgaine
- Re: [mmox] One more time: The LESS model vs the G… Jon Watte
- Re: [mmox] One more time: The LESS model vs the G… Charles Krinke
- Re: [mmox] One more time: The LESS model vs the G… Morgaine
- Re: [mmox] One more time: The LESS model vs the G… Jon Watte
- Re: [mmox] One more time: The LESS model vs the G… Jon Watte
- Re: [mmox] One more time: The LESS model vs the G… Morgaine
- Re: [mmox] One more time: The LESS model vs the G… Morgaine
- Re: [mmox] One more time: The LESS model vs the G… Kajikawa Jeremy
- Re: [mmox] One more time: The LESS model vs the G… Jon Watte
- Re: [mmox] One more time: The LESS model vs the G… Frisby, Adam
- Re: [mmox] One more time: The LESS model vs the G… Morgaine
- Re: [mmox] One more time: The LESS model vs the G… Charles Krinke
- Re: [mmox] 3-world OGP interop scenario Mark Lentczner
- Re: [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- Re: [mmox] 3-world OGP interop scenario Jon Watte
- Re: [mmox] 3-world OGP interop scenario Morgaine
- Re: [mmox] 3-world OGP interop scenario Charles Krinke
- Re: [mmox] One more time: The LESS model vs the G… Christian Scholz