[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction

[Stephen Rowles]

John, All,

Apologies, I won't be able to make the call today, I've been in other 
meetings all day and will still be in them for the call. I've chatted with 
Martin who will be able to represent my views for the purposes of the 
discussion,



Stephen Rowles




From:   John Arwe <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   22/08/2013 13:48
Subject:        Re: [Oslc-Automation] Temporary deployment solutions - 
tear-down plans - locating the plans in automated script construction
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



Martin, seems like a plan (heh) we can discuss on today's call at least. 
Hopefully both you and Stephen can make it. 


> * ... perhaps ":teardown") on the Plan ... value ...open for future 
extensions or provider-specific information (such as a parameterised 
plan). Perhaps ..., e.g. #required (i.e. highly desired) and #optional. 

Certainly seems reasonable at first blush that Automation could make that 
predicate's object a resource with it's own properties, and seed it with 
those you propose which I interpret basically as usage hints.  Let the 
"spirited naming discussions" commence [ducks, as he always does for 
those] on the predicate. 


> * The predicate on the Result ... have to define exactly what, possibly 
one of: ... 
>    (c) An automation plan (with no [required] parameters) - this is 
extensible to other executable things, like Actions, although that 
wouldn't be interoperable/backwards-compatible. 

To make use of a Plan, you also need a collection capable of fielding 
create requests for that Plan.  So this seems incomplete as written. Using 
the same resource "trick" that I mused about on Plan would allow that, 
even if the "shape" in this context is different.  That's allowed. 

One way to solve the compatibility issue (which, to be precise, is an 
*implementation* issue not a spec issue, if the spec's Range is Any per 
Core's guidance) would be to make it multi-valued, and make the semantic 
that each of the possibly multiple values is functionally equivalent; a 
client should choose at most one, presumably the one that it understands 
best, if >1 are offered.  If Automation provides one way to use that as a 
current basis for wide interop *and* allows others for future extension, 
implementation-specific extension, and/or implementation compatibility, 
that seems like a pretty good situation. 


Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130822/3ac79dfb/attachment-0003.html>