Re: [provision] statusReturns.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Has anybody thought any more about this issue?
1) Should the status operation by default return
    A) only "success", "failure" or "pending"?
    B) A, plus any (possibly partial) results/output/content?

Option A is lightweight (but is also perhaps a little "pessimistic").  
Option A is better if most requestors poll until an operation is 
complete and then (possibly) call once more for output.

Option B is more expensive (e.g., in terms of network bandwidth).  
Option B is better if most requestors are so interested in the output of 
operations that they are willing to process even partial results.

I can accept either approach as long as the protocol exposes an option 
(such as 'statusOnly' or 'includeOutput') that controls this behavior.  
Offhand, however, I prefer option A:
- Most requestors will want to know whether a requested operation has 
completed.
- Few requestors will need the output of  a requested operation.
  (e.g., the <pso> that is returned by an 'add' or the PSO-ID that is 
returned by a 'modify').
- Of those requestors that need the output of a requested operation,
   only a small percentage will want to process partial results (and to 
re-process them,
    skipping over ones they've already processed, each time they call 
'status').

gpc

Gary P Cole wrote:

> Jeff,
>
> Your suggestion of 'statusOnly' is an improvement on what we currently 
> have, but I think we need to take this a little bit further.
>
> 1) It appears to me that SPML 1.0 specified (what we would now call) 
> 'statusOnly' as the default so that a requestor could poll until an 
> operation was complete and *then* request the output (or "results").
> If we change this so that the 'status' operation returns output (or 
> "results") by default, then (by default) each poll would transmit data 
> (at least partially) redundant with (that of) the previous poll.
>
> 2) Even if we adopt the 'statusOnly' approach, I still need a term I 
> can use to describe the output (or "results") of a requested operation.
> I currently use the term "output" in the draft specification because I 
> found the distinction between "result" and "results" too confusing. - 
> StatusReturnsType#status actually requests the "result" attribute 
> (which is a value of type ResultCode).  Even with your suggestion, 
> 'statusOnly' actually requests the "result" attribute.
> - StatusReturnsType#result actually requests the *output* of the 
> operation (which is nowhere formally described, except perhaps in the 
> context of specific extensions of SpmlResponseType).
>
> I came up with the term "output" because "results" was simply too 
> close to "result". What about using the term "content"?
>
> 3) I think that the boolean option should request whichever behavior 
> is NOT the default.
>
> If returning results/output/content should be the default, then I like 
> your suggestion:
>
>    <attribute name='statusOnly' type='xsd:boolean" use="optional" 
> default="false"/>
>
> If returning only status/result should be the default, then how about
>
>    <attribute name='includeContent' type='xsd:boolean" use="optional" 
> default="false"/>
>
>
> gpc
>
> Jeff Bohren wrote:
>
>> IS this is confusing we should change it. I'm not thrilled with "output"
>> since this is a term we have not used yet. I would prefer to keep it in
>> terms that we already use. I also think the option of returning the
>> status and the resulting data should be the default. How about:
>>
>>    <attribute name='statusOnly' type='xsd:boolean" use="optional" 
>> default="false"/>
>>
>> Jeff Bohren
>> Product Architect
>> OpenNetwork Technologies, Inc
>>
>> Try the industry's only 100% .NET-enabled identity management software.
>> Download your free copy of Universal IdP Standard Edition today. Go to
>> www.opennetwork.com/eval.
>>
>>
>>
>> -----Original Message-----
>> From: Darran Rolls [mailto:Darran.Rolls@sun.com] Sent: Friday, 
>> November 19, 2004 1:45 AM
>> To: Gary P Cole
>> Cc: Jeff Bohren; PSTC
>> Subject: Re: [provision] statusReturns.
>>
>> I had trouble with this in 1.0 so i agree with (1); can't answer (2) and
>>
>> your (3) makes good sense to me...
>>
>> Darran
>>
>> Gary P Cole wrote:
>>
>>  
>>
>>> The 'status' operation can return either 1) the current state of the 
>>> target operation (which is executing asynchronously) or 2) any results
>>>   
>>
>>
>>  
>>
>>> of the target operation.  The optional 'statusReturns' attribute of 
>>> the StatusRequestType indicates whether the requestor wants the 
>>> provider to return #1 or #2 above.  The value of  "statusReturns" must
>>>   
>>
>>
>>  
>>
>>> be either 'status' or 'result'.
>>>
>>> Have I stated it correctly up to this point?  If not, please correct 
>>> me.  If so, hold on, because this is where I think it gets weird.
>>>
>>> If the statusRequest#statusReturns='status', then the provider 
>>> actually returns (in the SpmlResponse that is nested as 
>>> statusResponse#currentResponse) one of 
>>> {'success'||'failure'||'pending'}.  In other words, asking for 
>>> 'status' gets you "result".
>>> If the statusRequest#statusReturns='result', then the provider 
>>> actually returns (in the SpmlResponse that is nested as 
>>> statusResponse#currentResponse) any output thus far produced by the 
>>> target operation .  In other words, asking for 'result' gets you
>>>   
>>
>> output.
>>  
>>
>>> 1) Am I the only one who finds this confusing?
>>>
>>> 2) Doesn't status always have to return the "result" attribute (in the
>>>   
>>
>>
>>  
>>
>>> SpmlResponse that is nested as statusResponse#currentResponse) since 
>>> the "result" attribute is required?
>>>
>>> 3) Wouldn't it be simpler to have an optional attribute that asks 
>>> the provider to return output?
>>> Couldn't we replace 'statusReturns' with something like:
>>>   <attribute name='returnOutput' type='xsd:boolean" use="optional" 
>>> default="false"/>
>>>
>>> gpc
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the 
>>> roster of the OASIS TC), go to
>>>   
>>
>> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
>> kgroup.php.  
>>
>>>   
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster of
>> the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
>> kgroup.php.
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. 
>>
>>
>>  
>>
>
>