I studied your document on Link & Linking [1]. Nice write-up! When a Link is turned into a resource and thus exposed to CRUD semantics it will only be valid in the response to a GET request of an associated Resource, right? That is, using POST/GET/PUT/DELETE with e.g. a compute resource any Link headers will only be present in the GET response? If so we solve the problems of updating and removing links although we still have the the side effects when deleting a resource with associated links. I.e. that the DELETE operation of a resource should remove any associated links to avoid dangling links. Another problem with Link as a resource is that now there can be circular links and links pointing to other links. I think a problem here is that you try to model the concept of bi-directional links on top of Web Links which are strictly unidirectional (correct my if I am wrong). When you do this an important question to ask is what OCCI really is. Is it an interface or is it a representation model? If we decide OCCI is limited to be an interface I say unidirectional links are all we need. It is not up to OCCI to represent the relation between resources for persistent storage, it should merely be able to _display_ links to other resources. It is not like an IaaS provider would use OCCI as its internal representation format. Now, look at the analogy with web pages. A web page is a resource, that is easy to see and CRUD semantics apply as best they ever could. A web page may have links to other web pages, unidirectional links. Thus links will be removed when the resource is removed and referential integrity is not guaranteed. Why not apply the same model in OCCI? We leave the issue of referential integrity in the hands of the IaaS provider. If we create a compute resource with a link to a storage resource and then view the storage resource it is up to the provider to decide if a reverse link to the compute resource should be included in the response. Sorry if this last part was a bit confusing. I will add a proposal of my own to the Link & Linking document so we have a basis for discussion. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Ralf, Am 16.08.2010 um 16:46 schrieb Ralf Lyren:
When a Link is turned into a resource and thus exposed to CRUD semantics it will only be valid in the response to a GET request of an associated Resource, right? That is, using POST/GET/PUT/DELETE with e.g. a compute resource any Link headers will only be present in the GET response?
I would say yes. Since the creation is handled through the link resource, it shouldn't be done through OCCI Resources anymore.
If so we solve the problems of updating and removing links although we still have the the side effects when deleting a resource with associated links. I.e. that the DELETE operation of a resource should remove any associated links to avoid dangling links.
Agreed. I strongly believe that this should be something the server side should take care of.
Another problem with Link as a resource is that now there can be circular links and links pointing to other links.
This was not intended, but I see your point. Alas, the Link resource needs to have some kind of information on the source of the link, otherwise it will be difficult to keep track of dangling links. We probably have to state explicitly in the spec that the "source" attribute does not indicate a bidirectional link, but just indicates the source of a unidirectional link.
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Regards, Alexander -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
participants (2)
-
Alexander Papaspyrou -
Ralf Nyren