OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp] spec-2.0-draft-05: lifetime interfaces: comments


I would view the resource owner specifying a termination time sooner
than the current time + refresh duration as an error. Possibly a soft
error, in that a consumer may protect & recover from this. Then a call
to setTerminationTime() may be in order.

Regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com] 
Sent: 07 March 2005 10:35
To: Rich Thompson
Cc: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] spec-2.0-draft-05: lifetime interfaces: comments

Rich Thompson <richt2@us.ibm.com> wrote on 03/04/2005 08:48:20 PM:


> 5.1.21 Lifetime Type, page 31, lines 42-44
> Clarification question:
> Does the refreshDuration really change the terminationTime?
> Or is the terminationTime a function of:
> newTerminationTime=max(initialTerminationTime,
> lastAccessTime+refreshDuration)?
> Example:
> currentTime= 0:00, 01/01/05
> terminationTime= 0.00, 02/01/05
> refreshDuration= 3600
> Does that mean that if the Consumer accesses a Context at 11:00
01/01/05
> the terminationTime changes to 12:00 01/01/05?
> I think this is misleading, and we need clarification there.
> We should't require the Consumer to keep track with each request of an
> updated lifetime when the maxLifeTime is way in the future anyway.
>
> <rdt>I think the current lifetime should be bumped forward by the
> duration rather than it being a calculation based on the current
time</rdt>

I think we have a misunderstanding here.
The terminationTime in the lifeTime structure is an absolute time (the
*real*, *ultimate* destroy of the resource).
The refreshDuration is a relativeTime which pushes the terminationTime
ahead.
"If you use the resource, everytime you access it, I guarantee that it
will
be there for the additional "refreshDuration" period."

But: if both are given and lastAccessTime+refreshDuration <<
terminationTime, what should the Consumer assume as the *real*
terminationTime?
Which statement wins?
What I was asking for was the question if this statement is correct:
"The resource will be ultimativly destroyed at "terminationTime" (unless
requested to be refreshed), however on access I grant you availability
of
the resource by additional "refreshDuration".

If this is the case the function applies:
ultimateTermination=max(terminationTime,
lastAccessTime+refreshDuration),
correct?

cheers

Richard


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]