- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Fri, 1 Nov 2002 07:06:50 +0600
- To: "Joyce Yang" <joyce.yang@oracle.com>
- Cc: "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>
OK that's cool .. one way the other what I'm arguing for is picking one combination of the 4 ack/nack scenarios as the 80-20 case. Sanjiva. ----- Original Message ----- From: "Joyce Yang" <joyce.yang@oracle.com> To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> Cc: "WS-Desc WG (Public)" <www-ws-desc@w3.org> Sent: Friday, November 01, 2002 6:46 AM Subject: Re: [Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub > n the 80-20 rule, I'm not sure the "80" is on the no-ack case. > I think most subscription will need an ack. > > -Joyce > Sanjiva Weerawarana wrote: > > > On Thu, 2002-10-31 at 13:52, Joyce Yang wrote: > > > I'm not a fan of existing outbound operations, but I do see > > > them make the pub/sub modeling much easier and maybe > > > more close to the original idea of outbound operations. The > > > syntax Sanjiva proposed is very attractive (inline below), > > > > > > <portType name="pt1"> > > > <operation name="normal-op1"> ... </operation>* > > > <event name="event-1"> > > > <subscription message="subscription-message"/> > > > <notification message="notification-message"/> > > > </event> > > > </portType> > > > > > > however, it's not sufficient, we will have to invent many more > > > constructs to catch the concepts on whether the "subscription" > > > is with ack, and the "notification" is with ack or not. We > > > definitely can add a new "ack" attribute to <subscription> > > > and <notification> to serve the needs, but aren't they modeled > > > very naturally by two outbound operations as mentioned in my > > > proposal? But overall, I'm glad we are conceptually trying > > > to solve the same problem. > > > > I agree there are different variations possible as you noted. > > My approach to this kind of stuff is to take the most simple > > scenario and address that and see whether its enough. We can of > > course add whatever cases we want, but IMHO we should go for the > > 80-20 case only and live with that. Other more complicatated > > scenarios are left to extensibility. > > > > So my preference would be to pick the following choices: > > - subscriptions are not ack'ed by the event source > > - notifications are not ack'ed by the event sync > > > > Sanjiva.
Received on Thursday, 31 October 2002 20:09:24 UTC