- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 3 Jul 2002 20:49:51 +0100
- To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
- Cc: "'Mark Baker'" <distobj@acm.org>, Marc Hadley <marc.hadley@sun.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi Noah, > -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: 03 July 2002 19:02 > To: Williams, Stuart > Cc: 'Mark Baker'; Marc Hadley; 'xml-dist-app@w3.org'; > xml-dist-app-request@w3.org > Subject: RE: FW: LC Comments: Web Method Feature > > > Stuart Williams writes: > > >> Mandating its use (needlessly IMO) denies the > >> messaging/tunneling view. > > I don't think so. Seems Mark B would disagree with you about that, from [1]: > >> Mandating its use (needlessly IMO) denies the > >> messaging/tunneling view. > > For HTTP, yes it does, more or less. > All the admonitions to use GET vs. POST are SHOULDs. > Therefore a "tunnelist" can blindly use POST and get on with it, as he or > she always has. Well, you might say (I infer somewhat presumptuously), > why should a "tunnelist" even have to think about something so > disorienting as a feature having to do with HTTP and REST. To which I > would answer: > > * Because to use a binding such as HTTP you need to learn to use the API > documented for that binding. That API happens to have a property which > essentially is documented as "set this to GET if your a chameleon who > knows what you're doing and you care, otherwise use POST." So, not > caring, you use POST. Well, from my point of view that was the whole point of the feature/property abstraction. To a parcel that 'API' up into small reusable pieces and to create the binding 'API' as an assemblage of those pieces working as specified and where the user of that assemblage only has to deal with the pieces that they understand. The view that you promote now requires that the user of a binding has to recognise the named binding in addition to recognising the supported features (that it wishes to use) because the binding may introduce further constraints. IMO this view undermines the value of the framework that we have established... > * All of the properties are abstractions anyway. None of this requires a > typical user to bother or not bother with anything. I certainly agree on the implementation pragmatics here. > If you are building > an implementation that's intended for use only by tunnelists, nothing here > requires you to surface the choice to your users. Surely you had to set > the method to POST in the actual HTTP transmission in any case no matter > what architecture we chose, and that's all you have to do now. But... we could described this behaviour clearly and within the framework with the proposal that I made. At the moment... if the binding user doesn't use the Web Method feature (yes in the abstract) we don't define behaviour for the HTTP binding. > In other words, existing SOAP HTTP implementations are already more or less > compatible with the new binding, they just don't offer a level of control > over WebMethod that a chameleon should want. > > Cheers. > > Noah > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ Regards, Stuart [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0031.html
Received on Wednesday, 3 July 2002 15:52:08 UTC