Re: proposal for 7478

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