Re: [ws-caf] Action item for change timeout proposal

[Doug Bunting <Doug.Bunting@Sun.COM>]

With the caveat that I have not seen the changes that would consistently 
handle cases in which multiple contexts appear in the headers (making the 
"contextualized" referent below ambiguous), this looks fine to me.

With little worries either way, I might go further than the "don't garbage 
collect" restrictions below.  My preference would be the timeout parameter 
is immutable and updateTimeout disallowed unless the referencing 
specification allows both.

thanx,
	doug

On 26-Mar-05 06:27, Mark Little wrote:
> In the last teleconference I got an action item to further develop the 
> proposal for changing the timeout associated with a "running" activity. 
> I hope we're all now clear after the teleconference that the current 
> setTimeout operation on the context service only changes the default 
> timeout value associated with contexts created subsequently without the 
> timeout parameter on begin?
> 
> With that in mind, the discussion we had centred on having a proposal 
> for adding another operation to the context service that allows the 
> timeout for an existing activity to be changed, but to say that 
> referencing specifications MAY impose limitations on when it can be 
> used. That proposal is what follows:
> 
> That we add an updateTimeout operation to the context service. This 
> operation is contextualised, i.e., a valid context MUST be present with 
> the message. The context service then changes the timeout associated 
> with the context (which may be longer or shorter than the context's 
> current timeout value). Because the timeout value MAY be mutable, we 
> need to make it clear in the text that recipients of a context SHOULD 
> NOT rely upon the value for making local optimisations (such as garbage 
> collection) unless a referencing specification places limitations on 
> how/when updateTimeout can be used (at the limit, even making the 
> timeout value immutable).
> 
> Mark.