[mmox] Layering and separation of concerns...
David W Levine <email@example.com> Fri, 03 April 2009 19:57 UTC
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94B23A67D1; Fri, 3 Apr 2009 12:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([220.127.116.11]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jyxLc6NZAbp; Fri, 3 Apr 2009 12:57:19 -0700 (PDT)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [18.104.22.168]) by core3.amsl.com (Postfix) with ESMTP id 0A9643A682E; Fri, 3 Apr 2009 12:57:18 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [22.214.171.124]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n33Jt2g4027992; Fri, 3 Apr 2009 15:55:02 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [126.96.36.199]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n33JwLJh192978; Fri, 3 Apr 2009 15:58:21 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (188.8.131.5260308/8.13.3) with ESMTP id n33JwLIX029559; Fri, 3 Apr 2009 15:58:21 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [184.108.40.206]) by d01av03.pok.ibm.com (220.127.116.1160308/8.12.11) with ESMTP id n33JwKLu029556; Fri, 3 Apr 2009 15:58:20 -0400
To: MMOX-IETF <firstname.lastname@example.org>, email@example.com
X-KeepSent: FD8E28E4:B984AE3B-8525758D:006D4CB9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008
From: David W Levine <firstname.lastname@example.org>
Date: Fri, 3 Apr 2009 15:58:20 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 04/03/2009 15:58:20, Serialize complete at 04/03/2009 15:58:20
Content-Type: multipart/alternative; boundary="=_alternative 006DB5D28525758D_="
Subject: [mmox] Layering and separation of concerns...
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2009 19:57:20 -0000
Between a bunch of the discussion here, and some of the discussion last week at the IETF BOF, I've noticed a fair bit of what I'd describe as getting lost in the layering. A lot of this seems to happen because the Linden Lab grid is the main way people think about the problem space. The OGP drafts are pretty deeply steeped in Linden's terminology, and deployment model. OpenSim, tho different in some ways, is also a very specific bundling of function, and one who's shape is pretty strongly influenced by the shared Second Life viewer. I'd like to try and push fairly hard, to pull apart some important things, which *should* be thought of as totally separate. MMOX and OGP are attempts to describe a set of services, protocols, and serializations which will enhance interoperability in the Virtual Worlds/Immersive experience technology space. Starting most abstractly, OGP, and MMOX, describe an approach to solving the overall problem of creating and sharing the presentation of virtual spaces across many potential participants. We can then think of that approach as being broken up into a set of abstract building blocks, which are roughly speaking sets of named web resources, and services/protocols to map those building blocks onto internet deliverable chunks of function. Those chunks of functions get defined in detail (mostly as REST resources and protocols managed by the services, and in some low level mapping of concrete data structures onto web appropriate (read, XMLish or other structured format) representations. For added fun, we try, very hard to separate mechanism from policy, so that, we can speak of the set of REST resources which deliver a service in the model, and the set of policies which may control the use of that service. Finally, we have to separate in our heads, implementations and deployments of these services from their specifications. This frankly, along with the separation of mechanism from policy seems to be where we tend to get in trouble. Again, I think this to a very real extent stems from thinking very concretely about the current Linden Lab's SecondLife deployment, and from a set of documents which is very closely coupled to that deployment model. Exactly how people cluster services, should be, to a *very* large extent, separate from any specifications we create as part of the IETF/MMOX process. How they deploy services, the policies they apply to their deployments and the details of their implementations are totally outside of out interest, except when they impose constraints or requirements which affect interoperability. So, should a major set of deployers find a function missing, or impossible to separate from another function, that would be cogent input, and presumably shape future versions of the specifications. Any single implementer and deployer's choices of *how* to run their services, should be largely irrelevant. If you are still paying attention. 1) I don't believe *anything* in the way OGP gets defined as a set of services will dictate whitelists, blacklists, or similar common approaches to managing access. I firmly believe that we will put the right things into the protocol to permit people to build and deploy MMOX software which can use such techniques. I also, once again, observe that a core notion I have been advocating for a very long time, is to include the protocol elements permitting policy choices to be made, and then, permit people to not provide things such as authentication tokens, with the understanding that they may receive traditional web style 401 errors, if they don't provide those tokens to services which expect them. 2) There are a number of very different deployer models represented on the mailing list. Some, such as Linden Lab, and some large enterprise users, may have strong desires to bundle set of services to meet their needs. Others, may wish to unbundle some of the services, and deploy them independently. The only impact this ought to have on the actual services, is to levy a requirement that services not be overly coupled. Said requirement is inherent in good architecture, and should not be terribly controversial. At the same time, any single deployer, or contributor to this process, should be respectful of the full range of requirements we are trying to address. Dismissing someone else's use case as "not valid" is generally counterproductive. Understanding the use cases, and the desires which motivate them, and then working together to understand how we can support as broad a range of use cases as possible, is, in some very real sense the heart of the process. There are some nasty, hungry dragons in the "decompose the set of services very broadly" approach. It is possible to go from too tightly a coupled solution, where interop is obvious and inherent to too loosely a coupled solution where it is possible for two implementations to be fully conformant, and totally non interoperable. Classically such problems are addressed with "profiles" with decidedly mixed results. That said, I urge people to think very hard, as to at what level of layering something they find objectionable occurs. Look at whether we are conflating deployment and implementation choices as with design choices at the architecture and framework level - Catching up, very slowly, on MMOX mail, after 4 days off chasing dead hard drives and stuff stack up in the office, - David W. Levine ~ Zha Ewry (ISL) .