- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Tue, 16 Apr 2002 10:55:10 +0100
- To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
- Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi Noah, Firstly, as I hit the send button on my previous response I realised that I should have prefaced it with something like "think aloud" which was inspired by your message rather than being a direct response to it. > -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: 15 April 2002 15:18 > To: Williams, Stuart > Cc: Williams, Stuart; 'xml-dist-app@w3.org' > Subject: RE: Completing the tables SRR MEP description. > > > Thanks. I'm also curious about your reaction to my specific suggestion. I > am nervous about requiring even the simplest clients to handle the > overlap. What I was trying to do was agree with you that the possibility of deadlock was real, but disagree addressing this necessarily leads to significant complexity. I guess you made two specific suggestions a) Don't address it now... stick with a binding that doesn't allow the overlap. The overlapping case can be addressed later. b) The likely future solution being the defn of a header (SOAP or HTTP?) that signals the requesting nodes willingness to engage in overlapping request/response. I would be ok. if we made the first choice. In my previous response I did point out that (IMO) it introduces a conformance requirement that a responding node not begin the sending of a response before it has completely received a request. I believe that that is a direct implication of making that choice. On the nature of some future solution that involves the defn of a new header... I feel a bit nervous. The problem of overlapping request/response is not a SOAP specific problem. It's a generic problem at least for HTTP, I believe it is possible in BEEP and would be possible in a binding to TCP (say SOAP/DIME(for framing)/TCP). In the HTTP case, I think that *if* HTTP addresses the 'generic' problem then SOAP should be leveraging that solution, rather than re-inventing it. On yesterday's TBTF call I asked Henrik how the HTTP spec. handles this. On the call he said that HTTP requires that HTTP clients using POST MUST be capable of send and receiving concurrently and that HTTP requires this. I have tried to find this in RFC 2616 and so far I have failed. I'd appreciate a pointer to (spec.) chapter and verse on this. I expect that Henrik is correct and that HTTP does indeed require that HTTP clients that use POST (and I guess PUT as well) be capable of handling overlapping request/responses, then its a real possibility that the start of a response may show up before a request has been fully transmitted (likewise with BEEP). In discussion on the call, I agreed to explore the possibility of collapsing the MEP description into Requesting, "Requesting+Receiving", Success and Fail states at the requesting node and Receiving, Receving+Responding, Success and Fail at the responding node. Also to look at how this would effect the HTTP binding. I've committed to having this available for mid-week (COB Thursday UK at the lastest, earlier if possible) for consideration at TBTF call on Friday. > That seems like a big mistake. If Henrik is correct it is already a requirement imposed by the HTTP spec. > So: why not make the default "no overlap". > If you want streaming, then as a client, you must signal > that with a header. The header triggers a feature with the semantic that > the request originator MUST pull responses while sending the request, and > the responder MAY stream the response? I think that's very SOAP-like, > it's the best of both worlds, and the only downside is the need for the > client to include the header. Later, we could always name a separate > binding that mandates streaming in all cases. We could go that way... I'm not fundementally opposed to it. I think the problem is more generic to the underlying protocol, and any effective underlying protocol needs to have a solution for this type of problem within its spec, otherwise it itself admits the possibility of dead-lock which would be bad. *IF* HTTP already addresses this issue, I don't think that we should be re-solving it in SOAP. OTOH, if HTTP itself mandates not behaviour that avoids the potential for deadlock then we can use the kind of mechanism you suggest (assuming an SOAP header) to condition SOAP's use of the underlying protocol. > I strongly feel that the default binding should not put such a tricky > burden on the clients. Even though HTTP in prinicple always allows it, in > practice it's rare to have a large POST overlapped with a large response. > I bet that many stacks are buggy in this area or don't even try. Deadlock > is a very ugly failure mode. I think we should keep the base case simple, > especially since we have an easy way to the extension. I'm neutral as to > whether we should publish the streaming feature on day 1 and as normative. I'm not against doing as you suggest. However, I haven't yet concluded that we can't write a simply articulated specification for an MEP (and the HTTP binding) that allows for overlapping case and draws appropriate attention to requirements that HTTP clients using HTTP POST MUST/SHOULD be capable of concurrently sending and receiving. > Many thanks. > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ Regards Stuart
Received on Tuesday, 16 April 2002 05:56:23 UTC