RE: Issue 6432: updated proposal

Hi Li,
  this is part of the reason my original proposal included a rename of 
"Push" to something else like "EPRBased" to more accurately reflect what's 
going on (and I mean this for all cases - push as well as pull) - but some 
people wanted an even more minimalistic approach so I backed away from 
that part of the proposal.  However, given this discussion I'm thinking 
that perhaps we really should rename it - if Mode does live on.  Perhaps a 
Mode name of "UseWSA".

  When looking at the member submission version of WS-Eventing, its clear 
that the spec was written when WS-Addressing was still in its infancy.  It 
goes out of its way to talk about things that it really shouldn't - like 
how to use the wsa:RelatesTo header.  We don't need to discuss stuff like 
that since WSA covers it.  So, with this level of uncertainty about WSA 
its not surprising that the authors might have thought they needed as 
special Delivery element and Mode attribute.  However, now that WSA is 
well established, I think reexamining some of these decisions would make 
sense.  In particular, should the mechanism by which we say "send events 
here" really be that different from the mechanism by which we say "send 
replies here" ?  I don't think so. They are fundamentally the same thing - 
w.r.t. identifying the target for a message(s).  And given that 
wsa:ReplyTo seem to work just fine for replies (notice no need for a Mode 
attribute to get both push and pull type of interactions), I'm struggling 
to understand why a NotifyTo EPR alone isn't good enough.  So, +1 to Dave 
- remove Mode (if not the entire Delivery Element itself and just leave a 
NotifyTo EPR - after all, there are plenty of other xs:any's that could be 
used if other info is really needed - both in the NotifyTo as well as in 
the Subscribe - so I don't see any loss of functionality by doing so).

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/24/2009 06:42 AM

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