[Oslc-Automation] Potential new requirement

[John Arwe]

Query support is not an issue for the implementation that spawned this 
thread.  It is a different one than the synchronous case we've been 
discussing recently; most if not all of its requests will use the "asynch 
interaction style" that Automation is really geared toward.
Nothing wrong with the predicate being 0:1, so the implementation can 
calculate it on behalf of clients or not (clients calculate it via query) 
based on its primary use cases.
Note also that if the proposed "interaction style" changes are adopted 
into the spec then query over Results will indeed be required (MUST) as 
soon as the implementation either (a) implements a single asynch request 
or (b) wants to allow "non-synchronous-capable" clients ... i.e. the 
majority of them.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Charles Rankin/Austin/IBM at IBMUS
To:     oslc-automation at open-services.net
Date:   05/07/2012 10:47 PM
Subject:        Re: [Oslc-Automation] Potential new requirement
Sent by:        oslc-automation-bounces at open-services.net



oslc-automation-bounces at open-services.net wrote on 05/07/2012 04:00:46 PM:

> One of our potential implementations wants to be able to easily 
> retrieve only the most recently updated Automation Result for a 
> given Plan.  As they noted when they crafted their extension, any 
> Plan may have many Results (in-flight and/or completed).  They are 
> only interested in the most recently updated one. 

A few thoughts: 

1) I've found it more common to want to know the most recently created 
result, not the most recently modified one.  And, for the tools I'm most 
familiar with, this tends to be the default sort order for results (most 
recently created first). 

2) This seems like it is readily derived using OSLC query against the 
current resource definitions.  Granted this requires that the 
implementation support query. 

3) I suspect for most existing tools, this requires additional computation 
(for all naked GETs).  I wonder if this is used frequently enough to 
warrant that additional computation?  Or, in the reverse, I wonder if 
naked GETs will be used enough to worry about the overhead.  Of course, if 
we don't provide it directly, and it is common, then you end up needing 
query, which we aren't requiring. 

Charles Rankin


_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120508/ae64c59c/attachment-0003.html>