Re: [ogpx] issue : naming of capabilities in OGP

[Infinity Linden <[e-mail]>]

On Sun, May 31, 2009 at 12:38 PM, Larry Masinter <[e-mail]> wrote:
>
> The main thing that isn't clear is what the namespace denotes,
> though, and why any of the other existing capability namespaces
> aren't adequate.

the existing namespace is a collection of names that sort of "evolved"
during the OGP beta last year. things like "place/avatar" and
"remove/avatar." so the idea of having the URN is that it lets the
community define standard capability names while letting individual
deployers define new services or new revisions of existing services.

for example, let's say we defined a named capability that was used by
the client to signal the agent domain to begin the process of rezzing
an avatar somewhere. we might want to call it
"urn:ogp:/agent/avatar/place". this would be distinct from the
capability the agent domain requests from the region domain to place
the avatar, which might be called "urn:ogp:/region/avatar/place".
Someone at example.com might have an idea for how to improve this
process, and might define a named capability called
"urn:ogp:example.com/region/avatar/place". For the system to function
properly, we just need to make sure distinct capability names are...
well... distinct. this format (should) make it much more clear what's
going on when people are debugging the protocol stream. like someone
might look at the stream as part of debugging and go... "oh! now i
understand why this isn't working, it's cause we're asking the region
for the _regular_ avatar/place cap, not the example.com avatar/place
cap!!!"

it also allows two organizations: we'll call them example.net and
example.com to both create their own named capabilities for their own
experiments or custom protocols. and again... the purpose of the
distinct capability names is so the client may ask for distinct
capabilities that support distinct interaction semantics. if a server
provides both a standard capability AND a custom capability, it's
signaling the client that it supports both protocol flows.

> If the capabilities are about "world location", for example,
> or "presence information" about someone/someone's avatar's
> "location", why the namespace of geographic locations aren't
> used instead, etc. etc.

named capabilities denote a function, not a location. so you might
have something like "urn:ogp:/location/find" to request a capability
from a region domain that allows a client application to search for a
location "in world." So the caps namespace isn't the  same as the
namespace of public protocol endpoints, but rather a simple
identifier. In OGP, you request named capabilities after
authentication / authorization. So if you wanted to have each location
in the virtual world be addressable as a named capability, you would
end up having to relog every time you wanted to find information about
a new location.

hmm.. rereading the section of the auth spec or the intro/requirements
doc, it's not especially clear how named capabilities are to be used.
lemme try to post some more about that on the list this week. maybe we
could refine the discussion and find an succinct answer to the
question "what kind of services are requested with named
capabilities?"

-cheers
-meadhbh


>
> Larry
> --
> http://larry.masinter.net