It seems to me that, as an Event Sink, I would be aware that (a) I am using WS-MC and (b) I want new Notifications ASAP. In such a case, it would behoove me to make my polling loop very tight. In any case, I don't see how this concerns the Event Source at all.

- gp

Li, Li (Li) wrote:
Message
Doug,
 
That's exactly my point. MC approach entails some problems that I don't have to deal with if an addressable EPR is used. These problems occur in real-time communication web services.
On the other hand, i can use MC in situations where Push does work. For these reasons, it seems more appropriate if MC is included in a different mode. I am not against MC at all, i'm just showing that MC and "Push" are sufficiently different. In other words, merging MC into Push mode may limit its usage in future.
 
Thanks,
Li
 
-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, March 23, 2009 7:00 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject: RE: Issue 6432: updated proposal


Li,
  if you want to avoid this then make an endpoint available and provide an addressable EPR  ;-)    Doing something else more complex (like the flow you described) would require a brand new SOAP binding which is probably out of scope for this WG, and beyond what this issue is asking for.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



"Li, Li (Li)" <lli5@avaya.com>

03/23/2009 05:48 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>, "Chou, Wu (Wu)" <wuchou@avaya.com>
Subject
RE: Issue 6432: updated proposal







Doug,
That is a useful feature that can eliminate poll intervals if the events arrive at a steady rate relative to the poll rate, i.e. when you poll the i-th notification, the (i+k)-th notification already arrived to make pending=true. For an event series that does not behave this way, when does the next poll happen if a poll returns pending=false? If we poll immediately to ignore the flag, the next event may not arrive for sometime (so we waste some connection); if we wait as implied by the MC spec (to save connection), we increase the chance of delay.
 
 
thanks,
 
Li
-----Original Message-----
From:
Doug Davis [mailto:dug@us.ibm.com]
Sent:
Monday, March 23, 2009 4:30 PM
To:
Li, Li (Li)
Cc:
public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject:
RE: Issue 6432: updated proposal


Li,

 if you look at the MC spec there's a "MessagePending" header that can be used to indicate that the event sink should poll immediately when more messages are pending.  


thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.


"Li, Li (Li)" <lli5@avaya.com>

03/23/2009 03:42 PM


To
Doug Davis/Raleigh/IBM@IBMUS
cc
<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>, "Chou, Wu (Wu)" <wuchou@avaya.com>
Subject
RE: Issue 6432: updated proposal









Doug,

 

if so, that means only in the batch format can mc support timely delivery of notifications without the added latency compared to the "unsolicited push" mode.

 

this would work like this:

1) mc request (uuid=xyz)

2) subscribe (notifyto=xyz, format=batch)

3) all notifications sent using the same mc connection, until

4) the subscription terminates

 

i called mc request before subscribe to eleminate the potential delay caused by the mc request.

 

In a non-batch format, the sink polls the event source at some interval, so there is a added delay of

T(poll interval) + T(sending mc request) + T(processing of mc request)

 

To reduce the delay, we can make "poll interval" as small as possible (in fact we can make it zero using the batch format), but the tradeoff is we occupy more connection resources on the event source.

For this reason, i'm hesitating to merge these two approaches under the "push" mode.

 

Thanks.

 

-----Original Message-----
From:
Doug Davis [mailto:dug@us.ibm.com]
Sent:
Monday, March 23, 2009 2:50 PM
To:
Li, Li (Li)
Cc:
public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject:
RE: Issue 6432: updated proposal



Right -that's batching or box-carring.  And if we want to support that I think we need to define a new Format so it can be used regardless of whether we're pushing or pulling notifications.


thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

"Li, Li (Li)" <lli5@avaya.com>
Sent by: public-ws-resource-access-request@w3.org

03/23/2009 02:46 PM


To
Doug Davis/Raleigh/IBM@IBMUS
cc
<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>, "Chou, Wu (Wu)" <wuchou@avaya.com>
Subject
RE: Issue 6432: updated proposal











Doug,


I meant in one subscription created by mc, is it possible that one mc request will pull back mutiple queued messages, or is it always one mc request for one message.

Suppose there are two messages queued for a subscription, in the first case we have these messages:


mc request

msg1

msg2


in the second case, we can only have

mc request

msg1

mc request

msg2


thanks.


-----Original Message-----
From:
Doug Davis [mailto:dug@us.ibm.com]
Sent:
Monday, March 23, 2009 1:33 PM
To:
Li, Li (Li)
Cc:
public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject:
Re: Issue 6432: updated proposal



It depends on what you mean by multiple messages.  If you mean "batching" then sure that can be done but since this could be wanted even for Push style I think that's best left for the new Format element.  However, this can be very complicated though since some Notifications could generate faults and its not clear what the processing model would be.  If you mean "pulling from multiple subscriptions" then yes - you can do this optimization by using the same MCanonURI in multiple NotifyTo EPRs.


thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.
"Li Li" <lli5@avaya.com>
Sent by: public-ws-resource-access-request@w3.org

03/23/2009 12:34 PM


To
<public-ws-resource-access@w3.org>
cc
"Chou, Wu \(Wu\)" <wuchou@exchange.avaya.com>
Subject
Re: Issue 6432: updated proposal













Doug,

The MakeConnection standard suggests that the event sink initiates a
connection for each message. Is it possible that the event sink initiates a
connection for multiple messages?