[mmox] Layering and separation of concerns...

[David W Levine <[e-mail]>]

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)
.