RE: [wsn] Issue: TerminationTime property should allow Set/Update

["Murray, Bryan P." <bryan.murray@hp.com>]

Why would you not allow setting the TerminationTime in the future if you
use Set/Update? It is entirely possible that the termination time is
modified from the value the client sent in the request, but so what? If
the client sets the time 1/2 hour in the future and sends this message
every 15 minutes - what difference does it make if the client never
knows that the service is changing this 1/2 hour to 20 minutes?

Bryan

-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Friday, August 13, 2004 8:59 AM
To: Murray, Bryan P.
Cc: wsn@lists.oasis-open.org
Subject: Re: [wsn] Issue: TerminationTime property should allow
Set/Update





So I presume you told the developer that SetTerminationTime MAY set the
TerminationTime to a time in the future and that then requires the
return of the new TerminationTime.  This is different behavior from the
SetResourceProperties operation.  I am intrigued though by the notion of
allowing SetResourceProperties on TerminationTime.  I guess in this case
that the WS-Resource would be prohibited from setting the
TerminationTime to a time in the future or if it wanted to do so it
would be required to fault.

Tom


"Murray, Bryan P." <bryan.murray@hp.com> wrote on 08/13/2004 11:18:39
AM:

> I was approached by one of our developers regarding the 
> TerminationTime resource property in WS-ResourceLifetime. His comments
are as follows:
>
>
> There is a "TerminationTime" resource property, in addition to an 
> operation called "SetTerminationTime".
>
> To retrieve the value of the current termination time, you can make a 
> "normal" WSRF-RP GetResourceProperty call and ask for the 
> TerminationTime property - as dictated by the WS-RP spec.
>
> However, to set a new value, you MUST call the special 
> SetTerminationTime operation - the spec explicitly states, "A 
> WS-Resource MUST NOT allow the TerminationTime resource property to be

> modified by a SetResourceProperties request message as defined by 
> WS-RP".
>
> I don't see why the need for this distinction??  It makes implementors

> have to deal with this special case with no apparent need for it.
>
> Why can't the WSRF-RL spec rely on the setting capabilities of WSRF-RP

> just as it relies on the getting capabilities of WSRF-RP?  Why does it

> use GetResourceProperty but not SetResourceProperties and instead 
> define its own special operation for setting the property?  Seems like

> there is no real need for this special case - but yet it causes 
> implementors to have to write code for this "one-off" - we have here a

> required Resource Property that we must implement, but yet we must 
> "disable" some of the generic WS-RP functionality for this one
resource property.
>
>
> Bryan
>
> P.S. After I explained the reason for having the SetTerminationTime 
> operation, the developer agreed there was valid reason to have the 
> operation, but still felt there was no reason to have to write special

> code to disable the ability to use Set to modify the property. There 
> will be many clients that do not need to know exacly when the 
> termination time really is and will just periodically renew the 
> subscription until it is no longer needed.