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
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Mon, 7 Mar 2005 08:02:16 -0500
It sounds like we have a classic case
of something being underspecified. I think we have three obvious alternatives:
1. refreshDuration is added to the current
time to set a new termination time (overrides current one, though we could
introduce a requirement that it not reduce the duration until the termination
time occurs).
2. refreshDuration is added to the current
termination time to set a new termination time
3. Remove refreshDuration as it will
add too many DB access issues on both Producer and Consumer side to be
worth having it in the protocol.
Comments, preferences or other reasonable
alternatives?
Rich
Richard Jacob <richard.jacob@de.ibm.com>
03/07/05 05:34 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
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]