Re: [mmox] Layering and separation of concerns...

[Christian Scholz <[e-mail]>]

David W Levine schrieb:
> 
> 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.

[...]

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

+1

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

I am not sure I get this sentence ;-)
So are you saying that if a user does not provide some means of 
authentication to a service he has to expect a 401 response?
Seems logical (and how it's described in the OAuth spec IIRC plus during 
some AWG meeting).

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

Right. Also many API specs do exist already at least for the 2D space 
which could be used if they fulfill all requirements we have (but I 
don't expect them to be too different from e.g. social networks in these 
cases).

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

+1

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

Again in the 2D space there is some precedence in things like OpenSocial 
and the like. Using such formats would also give us the possibilty to 
hook up with existing social networks more easily.
In the 3D space things might be more complicated maybe simply because 
there is not so much work being done yet in specifying interoperable 
formats and protocols.

> 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,

I hope your hard drives are living again :-)

-- Christian


-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: [e-mail]
fon: [phone]
fax: [phone]

personal email: [e-mail]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net