[occi-wg] Another proposal on Linking

Tue Aug 17 06:17:38 CDT 2010

Ralf,

Am 17.08.2010 um 12:57 schrieb Ralf Lyren:

> 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.

ok.

> 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.

Well, actually I was tempted to suggest what you rule out below :-)

The reason for this is, rather than preaching of the "pure way of REST", that extensibility in links in OCCI core makes them conceptually resources in OCCI core. It then feels a bit awkward having the two classes separate, if a link gets its own subcategories with attributes and the like.

The question is: what makes them different from Resources if we go that path.

> 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?

I would really see some kind of resource (one of those you called "pseudo-resources") here. Of course, one would have to manage many more resource objects then...

We will have to decide between those paradigms: either make Links "Resources" (sort of), giving them subtypes and attributes and bells and whistles, or go for the other approach, where many more things would be modeled as (OCCI) Resources.

Best,
Alexander

> On Tue, 17 Aug 2010 11:48:33 +0200, Alexander Papaspyrou <alexander.papaspyrou at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Ralf Nyren
>>> Sent: Monday, August 16, 2010 7:09 PM
>>> To: occi-wg at 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 at 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 at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> 
> 

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100817/7858b4fb/attachment.bin 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100817/7858b4fb/attachment-0001.bin 