On Thursday 18 January 2007 09:08, Glynn, Eoghan wrote: > > (FWIW, I don't think it would be all that worthwhile to add a > > special interface at this point as the only case we would > > need it is the two way partial response. Seems much simpler > > to just put in a message.put(RESPONSE_CODE, > > 202) in RM like we do in SOAP for the time being. If we had > > another transport which required special syntax we could add > > extension points at that time.) > > Ok we're just going to have to agree to disagree on this. > > I really don't like setting the response code from outside the > transport.
I'm WAY WAY behind on this thread, but I really need to jump in on this point...... I COMPLETELY disagree with you on this one. There is NOTHING in the HTTP spec that says "RM partial responses are 202" or "SOAP faults are 500", etc.... Our HTTP transport should NOT have any of that stuff coded into it. The mapping of SOAP faults to response code 500 is part of the SOAP spec. Thus, the SOAP layer should be setting that. The RM response code mappings are part of the RM spec. The RM layer should be specifying that. There should not be any RM logic burned into the transports. That's bad. I'm OK with possibly adding a couple methods to help make the RM capabilities easier, but burning the logic into the transports is bad. Making the transports very complex to write is also bad. Anyway, I don't know all the details (I'm way behind on the discussion threads), but that point just jumped out as "not good." (IMO) -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
