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



Comments inline

Rich



Richard Jacob <richard.jacob@de.ibm.com>

03/04/05 07:18 AM

To
wsrp@lists.oasis-open.org
cc
Subject
[wsrp] spec-2.0-draft-05: lifetime interfaces: comments





5.1.21 Lifetime Type, page 31, lines 42-44
The unit (I assume seconds) is missing for the refreshDuration.

<rdt>The type is xsd:duration and is defined at http://www.w3.org/TR/xmlschema-2/#duration</rdt>


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>

5.1.22 RegistrationState Type, page 34, line 5
small typo, should be:

registration scope to the Consumer and indicate any change in the scheduled
destruction of the registration.

<rdt>Thanks ... Andre had also caught this</rdt>

5.1.23 RegistrationContext Type, page 34, lines 42-48
Shouldn't we mark the scheduledDestruction field more clearly as an Output
field only? It makes no sense for a Consumer to set this in the current
proposal.
It could make sense if we allow the piggybacking of a "renew lifetime"
request with these operations (saving roundtrips, but impacting performance
on the producer...). Need to discuss this.

<rdt>Sentence added to clarify this</rdt>

6.1.3 RegistrationContext Type, page 38, lines 21-27
Same as for 5.1.23

<rdt>likewise</rdt>

9.1 getRegistrationLifetime, page79, line 13-14
Typo, should be:

If the nillable response from this operation is nill, then scheduled
destruction is not in use for this registration and the Consumer MUST use
the deregister operation to destroy the registration.
<rdt>Good catch ... thanks</rdt>

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


---------------------------------------------------------------------
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]