[occi-wg] Its all about Location, location, location

[alexander.papaspyrou at tu-dortmund.de]

Hey Gary,

comments inline.

Am 07.04.2011 um 16:19 schrieb Gary Mazz:

> Agreed, but the spec doesn't say that. We've been looking at the specs and have a severe bias, at least in terms of implied meaning, that other readers don't have.

Agreed. Maybe this should be stated more clearly.

> The policy for managing the name space is critical to ensure interoperability across providers. We need a reference for the start of the user name space.  For example, the provider may organize consumer facing name spaces by [authority, user name space, location]  while others may use [authority, location] and other may offer [authority, [user defined name spaces], location] . Each scheme has its own merits and proprietary value, we just need to way to reconcile the start of the user's name space so transposition works the same way across providers.

Ah, the screams of "Don't imply structure on the namespace beyond the query interface" on the list will be deafening...

Seriously: this has been a constant matter of discussion, and I remember the Brussels OGF last year where I had extensive flamewars with Thijs on this. The contrary position is: each provider should be able to structure his namespace as he wants (so as to ease the burden of adopting OCCI).

The compromise was to make the structure of the namespace discoverable via the query interface. 

> Having said all that and a personal preference, I strongly endorse the idea the OCCI HTTP specification mandating a fixed name space. Right now we don't. I just have a tough time believing that a fixed scheme fits all grid, private cloud and other provider naming conventions and feel obligated to support them.

+1 from my side. OTOH, *because* it will be difficult to find a common namespace, I am happy to live with the discovery indirection. The downside is that clients that aim to be interoperating have to do more work :-(

-Alexander

> 
> -g
> 
> On 4/7/2011 2:22 AM, alexander.papaspyrou at tu-dortmund.de wrote:
>> Hi Gary,
>> 
>> even for multi-tenant systems, this shouldn't be a problem: GETting the location path should only give back those resources that are supposed to be visible to the customer. Even more: from the specs perspective, noone prevents an implementor from giving back different locations, depending on the principal of the GET request (at least that's how I would interpret it).
>> 
>> -Alexander
>> 
>> Am 07.04.2011 um 06:32 schrieb Gary Mazz:
>> 
>>> Hi,
>>> 
>>> The location is defined :
>>> 
>>> Location paths tell the client where all resource instance of one Kind
>>> or Mixin (in case the Mixin is used as a tag) can be found regardless of
>>> the hierarchy the service provider defines.
>>> 
>>> This language poses a problem in multi-tenant and where Kind/Mixins are
>>> placed in hierarchically managed name spaces. Stating the location is
>>> reference at the user's (consumer's) top level name space may be a
>>> clearer way of defining its role.
>>> 
>>> cheers,
>>> gary
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> 
>