[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsn] Issue: TerminationTime property should allow Set/Update
Ouch, the semantic of SetResourceProperties is to set the RP to the value specified. Would you say the behaviour was okay for non-monotonic changes or for other resource properties? Can a service just decide to put whatever value it feels like in an RP and return a non-fault response? Tom "Murray, Bryan P." <bryan.murray@hp.com> wrote on 08/13/2004 01:41:25 PM: > 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]