[occi-wg] Removing associations between resources

[Ralf Nyren]

On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX  
<andrewx.edmonds at intel.com> wrote:

Hi Andrew, thanks for your response!

> Semantics related to removal/deletion of Link, in my view should be  
> divided into two separate but complimentary areas:
> 1) Unlinking - to unlink one resource from another the use of PUT should  
> be used to update the appropriate resource

I agree, the use of PUT to remove an association between two resources is
how I would want it.

The question is though, how to express the removal operation using the
Link header?

> 2) Destroying a link - to destroy a link resource it must be unlinked  
> from dependent resources using PUT and then finally destroyed using  
> DELETE. If a user attempts to destroy before unlinking then the server  
> should raise an exception. That way there are no dangling references to  
> non-existent resources.

By a "link resource" you mean an association applied to a Resource, right?
That is, an association/link can never exist on its own?

The way I view things the unlinking operation would not be necessary. Let
us say we have a compute resource '/compute/vm01' and a storage resource
'/storage/san01'. We then decide to associate these two resources by a  
link.
This can be accomplished by two different PUT request:

We could make a link from the compute resource to the storage resource,
e.g. "add a disk":
PUT /compute/vm01 HTTP/1.1
Link: </storage/san01>; class='link'; rel=...

Or we could make a link from the storage resource to the compute resource,
e.g. "make the disk available to the virtual machine".
PUT /storage/san01 HTTP/1.1
Link: </compute/vm01>; class='link'; rel=...

Now, since there is only one association here, removing either compute or
storage resource would also destroy the association. An association between
two resource can only exist as long as both resources exist.

If you view things this way you can never have dangling references.

What do think of this approach? I might just have misunderstood something
though...

regards, Ralf