Subject: [mmox] Zero's Office Hours, April 7th

From: Mark Lentczner <[email-masked]>
Date: Fri, 3 Apr 2009 11:24:11 -0700

My in-world (Second Life) office hours will be held next Tuesday,  
April 7th, from 1pm to 3pm.

Please place agenda items for consideration on my wiki page:
	https://wiki.secondlife.com/wiki/User:Zero_Linden

Preference will be given to agenda items with concrete technical  
discussion, especially those with written documentation available  
prior to the meeting.  Please link documentation from the wiki page.

For those that haven't attended before, my office hours are held once  
a month to discuss the development of the OGP protocol, and other  
technical issues about the architecture of systems that can/could  
support OGP. The discussion is held in Second Life, using text chat,  
and transcripts are published publicly (see the wiki page.)

	- Mark / Zero

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: David W Levine <[email-masked]>
Date: Fri, 3 Apr 2009 15:58:20 -0400

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Apr 2009 13:22:05 -0700

Mark Lentczner wrote:
> My in-world (Second Life) office hours will be held next Tuesday, April 
> 7th, from 1pm to 3pm.

what timezone?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Christian Scholz <[email-masked]>
Date: Tue, 07 Apr 2009 00:05:27 +0200

> things, which *should* be thought of as totally separate.

[...]

> deployer's choices of *how* to run their services, should be largely

+1

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

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

> very real sense the heart of the process.

+1

> such problems are addressed with "profiles" with decidedly mixed

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.

> conflating deployment and implementation choices as with design choices 
> at the

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: [email-masked]
fon: +49-241-4007300
fax: +49-241-97900850

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