Alexander, Thanks for clarifying the Thin Link proposal. I would like to let the discussion of "Link as a resource or not" rest for a while and only focus on Thin vs Fat Links for now. You state simplicity and non-extensibility as design goals of Thin Links. I understand your motivation but must object against the "no extensibility" part. I cannot see how non-extensible Thin Links could meet the real world use cases OCCI has to cope with for wider adoption. From my point of view there will always be use cases where it is necessary to express attributes of the relation between two resources, attributes which have no meaning without the relation. The alternative would be some sort of pseudo-resources existing only for the purpose of containing relation attributes but that does not seem like a clean approach to me. Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people). The disk controller attribute cannot be stored as a Compute attribute since it is irrelevant without the associated disk and a Compute resource can be Linked to many Storage resources. The disk controller attribute cannot be stored as a Storage attribute since the Storage resource can be Linked to many Compute resources. How do we solve this scenario with Thin Links? regards, Ralf On Tue, 17 Aug 2010 11:48:33 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
Ok, to further confuse the situation, I decided to write down the "thin link" proposal [1] we have been discussing as one alternative during the last telco.
Wearing my fire-proof pants...
-Alexander
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Am 17.08.2010 um 01:04 schrieb Edmonds, AndrewX:
Nice work Ralf! I like this, is KIS and covers the need for specialized/extended Link types. The only real difference with this and the previous is that the lifecycle of the link is managed by the source Resource and as such makes the association a composition. As it is a composite association there is no need to explicitly interact with the link via HTTP verbs but rather indirectly via its owning source Resource.
To your question "Is it an interface or is it a representation model?" - It's both. The interface is the means by which we manipulate the model.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, August 16, 2010 7:09 PM To: occi-wg@ogf.org Subject: [occi-wg] Another proposal on Linking
While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach?
Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach.
I am very much looking forward to your comments.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg