- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Mon, 21 Sep 2009 08:26:28 -0700
- To: "Li, Li (Li)" <lli5@avaya.com>
- CC: public-ws-resource-access@w3.org
- Message-ID: <4AB79B24.9030300@oracle.com>
Li, I don't know how an Event Source is supposed to be able to tell the difference between "T1 = infinity means I don't care what the expiration is" and "T1 = infinity means I need a Subscription that never expires". The same value is being communicated in both cases (BTW neither xs:duration nor xs:dateTime have "infinity" in their value space). - gp On 9/21/2009 7:35 AM, Li, Li (Li) wrote: > > Gil & Doug, > > > > I don't feel option (a) is equivalent to current spec, since in (a) > subscriber cannot provide any expiration value for event source to > shoot for (using the best-effort strategy). On the other hand, I think > the current spec covers the options in your proposal as follows: > > > > Current spec: subscriber asks for expiration T1 > 0, event source > returns a subscription with T2 > 0. > > For (a), T1 = infinity, T2 > 0 > > For (b), T1 = infinity, T2 = infinity > > For (c), T1 > 0, T2 >= T1 > > > > I think the current spec provides a more generic framework from which > these options can be derived. This means an event source can restrict > the framework to fulfill your requirements. For example, if you > implemented the latest and greatest event source that never cuts off > the requested expiration as in (c), you can advertise that in the SLA > (maybe using policy) of the event source. Any subscriber following the > generic framework should be interoperable to that event source without > any change. > > > > Thanks, > > Li > > ------------------------------------------------------------------------ > > *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com] > *Sent:* Thursday, September 17, 2009 3:23 PM > *To:* Li, Li (Li) > *Cc:* public-ws-resource-access@w3.org > *Subject:* Re: proposal for 7478 > > > > (too add to the other threads on this subject) > > I think you are missing an important aspect in the proposal and that > is that the Subscriber is provided with a greater/clearer range of > expression with regards to expiration. The Subscriber can now say (a) > "I don't care when/if this Subscription expires", (b) "I need a > Subscription that never expires", (c) "I need a Subscription that, if > it does expire, expires no sooner than X". Option (c) is a new > feature. The member submission, effectively, only allowed for (a) or > (b). True, the Subscriber was allowed to provide an expiration time > but, since the Event Source was allowed to ignore it, you end up with > (a) - the Subscriber/Event Sink had to be able to deal with whatever > the Event Sink decided upon. > > If you have a use case in which the Subscriber "may want to accept a > Subscription with a shorter expiration, with the hope that it can > renew it later on when the event source is less loaded", that > Subscriber should use option (a). You don't have to use option (c) and > "repeatedly submit subscriptions with shorter expiration in order to > be accepted". > > - gp > > On 9/16/2009 7:19 AM, Li, Li (Li) wrote: > > This response concerns point 2) and 3) in the proposal as point 1) is in > a separate issue and point 4) depends on 2) and 3). > > This proposal changes the current WS-E draft in the following ways: > > 1) It removes the possibility for an event source to return an > expiration that is less/earlier than the value requested by the > subscriber in a successful subscription; > > 2) It removes the following paragraph from the definition of Expires > element in Section 4.1: > > If this element does not appear, then the request is for a subscription > that will not expire. That is, the subscriber is requesting the event > source to create a subscription with an indefinite lifetime. If the > event source grants such a subscription, it MAY be terminated by the > subscriber using an Unsubscribe request, or it MAY be terminated by the > event source at any time for reasons such as connection termination, > resource constraints, or system shut-down. > > By change 1), it assumes all subscribers will never accept any > subscriptions with a shorter expiration. Therefore, there is no need to > create such subscription in the first place. While this may be the case > in some situations, I'm not sure WS-E should enforce this assumption for > all situations. In some situations, a subscriber may want to accept a > subscription with a shorter expiration, with the hope that it can renew > it later on when the event source is less loaded. In some cases, getting > some notifications now is better than getting no notifications at all. > If we remove this flexibility, a subscriber desperate for notifications > has to repeatedly submit subscriptions with shorter expiration in order > to be accepted. Therefore, I feel this restriction should be enforced by > the event source implementations, instead of the spec itself. > > By change 2), the proposal gives the people impression that an > indefinite subscription cannot be terminated by the event source. > > Thanks, > > Li Li > > > >
Received on Monday, 21 September 2009 15:27:26 UTC