Good idea. OOB communication – we should make it a JSON file which could have the CDMI metadata – that way we have a standard vocabulary.

If that is the case, why not it be the container metadata queried by a GET ?

Gary, would JSON over HTTP from a well known URL work as communication mechanism ?

Cheers
<k/>


On 5/12/10 Wed May 12, 10, "Mark Carlson" <mark.carlson@oracle.com> wrote:

Thanks Krishna.

I was thinking of how to convey the information that is not available through
CDMI to the implementation of OCCI and was thinking of a special file system
(not CDMI exported, but always available) that was exported from the CDMI
system to the OCCI system. On this filesystem would be one or more files where
CDMI puts the information needed by OCCI to do the mounts, etc. When the
Client makes the call in 3), the OCCI implementation would re-query the file
and get the information needed. i.e "write-only" by CDMI and "read-only" from
OCCI.

Thoughts?

-- mark

On 5/12/10 3:43 PM, Krishna Sankar wrote:
Cloud Demo 1st Cut Choreography
After today’s discussion, Mark asked me to capture the sequence. Here is 1st Cut:
 
  
  1. Client -> CDMI : Create container - create object. Metadata to include [type = export, Display Name, Canonical Name, Mount Point, Security Tokens]
  2. CDMI -> creates container, object and prepares the export as mount point
  3. Client -> OCCI : XML or JSON call with [Display Name, Canonical Name, Mount Point, Security Tokens]
  4. OCCI Layer : Mounts the mount point and displays the [Display Name]


OCCI Layer can try this without CDMI just by stubbing the Client->OCCI call with XML/JSON. That way we can develop the pieces in parallel.
 
After this is working, we can try OCCI to CDMI direct route
 
Cheers
<k/>
P.S : As discussed today, we have many of these pieces working incl parts of OCCI, CDMI(Capability,Container,Object), the computer hardware infrastructure (at SNIA) and the Client code.