Re: Comments on the "drop response-only" Part 2 draft
David Hull <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
Dave, Sorry, I'd meant to ask this sooner (I think it came up earlier as well). As I understand it, your current draft has /both/ the SOAPiness of the response and the response itself optional. Is this correct? If so, why? This seems to say pretty much nothing about what the underlying protocol provides: You can send me a request, and I might send something back, and it might be SOAP. If I'm using WSA, I would like to know whether it's safe to use an anonymous response endpoint. If the binding in question supports request-response, then I know that I can use anonymous and the server can send me a response anonymously. If I'm using "I might send you something that might be SOAP", do I still have that guarantee? If so, it seems clear that this could not be bound on top of any of the several one-way protocols that have been mentioned (not that I think it should be -- as I've said, F&F should be available for such protocols). As to the question of state machines or no, I'm not sure I care that much. As I've said [1], I don't think that MEPs alone capture what needs to be captured about underlying protocols. Charter questions notwithstanding, it would be a shame to concentrate too narrowly on MEPs, since it appears [1] that much of this is easily and usefully captured. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html David Orchard wrote: >Thanks for the review. I think that the small amount of comments shows >how fairly straightforward it is to refactor the spec and how quickly it >could proceed through the w3c process. I can certainly live with >keeping the response-only mep if that would gain people's support. I >again assert that the state machines have not served our community and >have hindered the specification and deployment of new MEPs and bindings. > > >The WG has now spent a fair amount of time examining the refactored MEP >approach, and we've had some detailed comments. It seems to me that we >have largely and well covered the ground. I thank the WG for the time >and diligence in examining the options available. > >I think that it's now time to call the question on which approach to >follow. We have sufficient information afore us to make a decision and >proceed. I'd like to query the WG members to find out who supports the >state machineless MEP approach for our direction on the >request-optional-response problem, vs who supports the state machinefull >(status quo) MEP approach. > >Cheers, >Dave > > > >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] >> >> >On > > >>Behalf Of [email protected] >>Sent: Wednesday, January 25, 2006 7:10 AM >>To: [email protected] >>Subject: Comments on the "drop response-only" Part 2 draft >> >>First, thanks again to Pete for providing the diff markup [1] on >> >> >Dave's > > >>draft. My earlier note pointed out that the diffs don't catch >> >> >everything > > >>of significance, but they are very helpful! >> >>Last week I took an action to provide detailed comments on Dave's >> >> >draft. A > > >>marked up copy is attached. I started with Pete's diff and added my >> >> >own > > >>comments as additions. The changes I made were: >> >>* My comments have a yellow background and all contain the flag >>***NOAH*** to make them easy to find. >> >>* So I could use yellow for my comments, I change the diff markup to >> >> >use > > >>an acqua color for additions. It should be self evident when you look >> >> >at > > >>it. >> >>Sorry I didn't get this done earlier, but I hope it will still be >> >> >useful > > >>on the call. This exercise has reconfirmed my personal position on >> >> >what > > >>we should and shouldn't do. >> >>* Because of its impact on the spec, because I believe the whole point >> >> >of > > >>MEPs is to allow applications to identify the differences and the >>commonalities between what different bindings provide, and because I >>continue to believe after this week's discussion that one way and >> >> >req/resp > > >>are deeply and appropriately different, I am strongly opposed to >> >> >merging > > >>request/response with response only. Keep the two MEPs. >> >>* In other respects, I continue to think that the editorial direction >> >> >of > > >>dropping the detailed state machines is beyond what we need to do to >>succeed now, but I'm not against it on technical or editorial grounds. >> >> >As > > >>noted in my comments, Dave has kept more detail in the binding than in >> >> >the > > >>MEP, and I think if we do decide to drop the full state machines the >> >> >MEP > > >>descriptions should at least have detail similar to what's in his >> >> >binding > > >>writeup. Not a big deal I think. >> >>Bottom line: I'd prefer to go with something closer to the draft I >> >> >sent > > >>[2]. I think it easily meets the requirements we've been given, and >> >> >is > > >>much closer to the minimal needed to declare success. At this point >> >> >in > > >>the life of our workgroup, I think we should take such paths when >>reasonably possible. Stability is important, and I'm not convinced >> >> >that > > >>the state machines as documented are proving a big barrier to those >> >> >who > > >>need to figure them out. I do agree that they are cumbesome. I was >> >> >never > > >>enthusiastic about them and I'm still not, but they were a compromise >> >> >we > > >>made to get consensus of those who joined the group to create SOAP. I >>don't think we've had a tremendous amount of "new information" to >> >> >suggest > > >>reopenning our status quo on them. If the group decides to do so, I >> >> >think > > >>Dave's editorial style signals a good direction, modulo the specific >>details mentioned in comments. >> >>Note that I will be on the call today, but must send regrets for next >>week. Thank you >> >>Noah >> >>[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0124.html >>[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html >> >> >>-------------------------------------- >>Noah Mendelsohn >>IBM Corporation >>One Rogers Street >>Cambridge, MA 02142 >>1-617-693-4036 >>-------------------------------------- >> >> >> >> > > > > >