One thing to keep in mind is that
producers may not particularly respect consumer requests and consumers
adjusting is more likely when the termination time nears (so as to be favorably
viewed by the resource maintainer). Therefore, I did not include a
requestedLifetime in all operations.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 22 December 2004 03:09
To: WSRP
Subject: Re: [wsrp] Issue #32:
Pass requestedLifetime to relevant opreations
I believe this was one where you were the source :}
The
reasoning is that if the Consumer doesn't have a chance to request a particular
lifetime, there will be an additional network round trip just to do an initial
setup.
This
is one where I could easily be convinced either way. Draft 04 has it that the
Consumer discovers that the Producer is using scheduled destruction by the
appearance of a lifetime in the reply. I suspect Consumers would then add this
as a resource to manage relative to the renewal of the lease and therefore not
incur an additional roundtrip. The flip side is that if the Producer is using
leased resources (Consumer should be able to tell by support for the respective
portTypes), why shouldn't the Consumer get a chance to indicate its preference
for the initial timeout?
Rich
Michael Freedman
<Michael.Freedman@oracle.com>
12/21/2004 12:55 PM
|
To
|
WSRP <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
|
Re: [wsrp] Issue #32: Pass requestedLifetime
to relevant opreations
|
|
Why?
Rich Thompson wrote:
Issue # 32
Spec section:
SubCommittee: Interfaces
Owner: Andre
Description: Operations
expected to return a Lifetime should also take one as input. This would affect
register, modifyRegistration, clonePortlet, exportPortlets, copyPortlets.