Re: [provision] Keeping results of asychronous operations.

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

That makes sense.  It would be nice for a provider to advertise its 
retention limit, but this doesn't exactly rise to the level of protocol 
specification.  I can also see that one requestor checking results of an 
operation shouldn't necessarily trigger a provider to delete those results.

Hal Lockhart asserted in Tuesday's conference call that a specification 
should not guard against non-functional implementations.

Does anyone have a problem with taking a line like the one that Jeff 
proposes?

Jeff Bohren wrote:

>I am afraid I don't see the value of this issue being addressed in the
>specification. That the status is retained for some time period should
>be self-evident, otherwise there would be no reason to have a status
>request. However the specific time period is up to the service
>implementer. 
>
>I am not comfortable with not keeping the status after a status request
>is done. The problem with that approach is that the client may have
>issued a status request but there may have been a failure to process the
>status results.
>
>The only way I would address this in the spec would be something like:
>
>"The service SHOULD maintain the status of asynchronous requests for the
>purposed of responding to status requests for a specific duration, where
>that duration is published out-of-band to potential clients."
>
>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: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Friday, October 29, 2004 10:04 AM
>To: Darran Rolls; Jeff Bohren
>Cc: PSTC
>Subject: Re: [provision] Keeping results of asychronous operations.
>
>I like that idea, too.  I think Jeff Bohren would be most likely to have
>
>a contrasting opinion.
>
>Jeff, how could/should/would a provider specify a time limit on async 
>results as part of the Async Capability?  Is this a terrible idea?
>
>Darran Rolls wrote:
>
>  
>
>>I like 1 & 1b with the assumption that the service can "advertise" its
>>    
>>
>
>  
>
>>retention timings as part of the service definition.
>>
>>Darran
>>
>>Gary P Cole wrote:
>>
>>    
>>
>>>A provider will eventually want to forget about a completed 
>>>asynchronous operation. I can think of two approaches.  Neither 
>>>approach excludes the other.
>>>1) A provider can save the results of asynchronous operations for a 
>>>certain amount of time.
>>>2) A provider can send a final, unsolicited response to the
>>>      
>>>
>requestor.
>  
>
>>>I prefer the first approach.  I like the simplicity and consistency 
>>>of a response always being a synchronous reply to a request.  
>>>(However, if someone wants to make a case for the second approach, 
>>>I'll listen.  Neither approach excludes the other.)
>>>
>>>Assuming the first approach, we still have options to consider. 1a) A
>>>      
>>>
>
>  
>
>>>provider should keep results for each completed asynchronous 
>>>operation for a certain amount of time.
>>>1b) A provider should keep results for each completed asynchronous 
>>>operation for a certain amount of time OR until a requestor uses the 
>>>status operation to obtain the final results of the operation, 
>>>whichever comes first.
>>>
>>>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.
>
>  
>