I tend to be in agreement with Alex on this one. We are assigning a life cycle to a link element intended to represent an association between resources. Its the association, an implicate resource property, represented by the link (as the implementation) that is constructed and deleted. The OCCI challenge surrounding this discussion is founded in how storage and network resources exist in the OCCI model when not attached to a Compute resource (orphans). Once we clearly define how and where they exist, resource life cycle practices can be developed around it. Then we could consider using verbs including using CRUD update (via a configuration definition) and the OCCI verb Move. cheers, gary Alexander Papaspyrou wrote:
Personally, I think this is a really bad idea, since we are breaking the traditional semantics of HTTP and REST.
If there is a need for a lifecycle of a link, then the link should be a resource, and not some header construct. Otherwise, it should never be altered by the client, but instead, fully managed by the server. That is, if a resource gets deleted, the server should be responsible for finding and updating all dangling links and, on the next GET or HEAD for any affected resource, return the correct data.
Really, guys -- we are imposing additional CRUD semantics on the headers here. Shouldn't do that, though.
-Al.
Am 10.08.2010 um 15:09 schrieb Ralf Nyren:
On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@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 _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg