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

["Andre Kramer" <andre.kramer@eu.citrix.com>]

I agree that a lot of questions about the contract details can be
raised. I would punt to the WSRF work (drafts on
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf) and
make use of a 'under-specified as designed, consume must take care'
principle: the exact leasing contract is deliberately vague and a
consumer should be conservative in interpreting leasing time values.
E.g. consumer should somewhat urgently set the termination time (with
setTreminationTime()) if value returned is too close to the consumer's
current time of last use and the portlet is expected to be used again in
future. That's not to say we should not point out potential problems and
give guidance but we definitely do not want to nail down every detail.

Regards,
Andre

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

agreed, makes no sense.
But the Producer only sets this on the initial request only (either
implicitly on the lifetime operations, or on the setXXXLifetime
operations).
But eventually this will happen.
My understanding of refreshDuration is an implicit means for the
Consumer
to assume the lifetime of a resource on a per-access basis.

Again an example:
terminationTime: 01:00:00, 02/01/05
currentTime: 00:00:00, 01/01/05 (time of resource creation)
refreshDuration: 1 Week

So if the Consumer accesses the resource at 00:00:00, 02/01/05 then the
terminationTime automatically changes to 00:00:00, 02/08/05.
But for example in week 1: 01/01/05 - 01/08/05 the terminationTime still
is
01:00:00, 02/01/05.

While thinking about this the question comes into my mind:
Or is the lifetime returned in the contexts with every response? (I
assume
the answer will be yes :-) ).
In that case do we need to restrict the Producer not to change the
terminationTime to an earlier time, and refreshDuration to a smaller
value?
I wouldn't like to require the Consumer to check these values with every
request and potentially store them in the DB.
Especially the refreshDuration approach seems to me to have many
implications on performance in terms of DB write accesses.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


 

             "Andre Kramer"

             <andre.kramer@eu.

             citrix.com>
To 
                                       Richard Jacob/Germany/IBM@IBMDE,

             03/07/2005 11:41          "Rich Thompson"
<richt2@us.ibm.com> 
             AM
cc 
                                       <wsrp@lists.oasis-open.org>

 
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