RE: proposal for 7478

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