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?