Thats way too complicated and gets in the way of too many things. The info should be passed to occi via the client. If the CDMI config changes, the client needs to update the occi server.

-g

On Wed, May 12, 2010 at 4:25 PM, 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:
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.