- From: Paul Prescod <paul@prescod.net>
- Date: Thu, 25 Apr 2002 16:56:07 -0700
- To: David Orchard <dorchard@bea.com>, www-tag@w3.org
David Orchard wrote: > > Paul, > > I can't read every message that goes through my mailbox. In the past 3 > months alone, I've gotten an average of 4 emails a day from you (369 to be > exact). And they are all typically long. Granted, some are duplicates, but > it's still impossible to read every new message. Understandable. They are mostly repetitive because nobody else reads the all either. ;) > However, on this one I went through each of your links listed. I never > found something along the lines of "If you do POST always, xyz will happen > and they are bad". You've said that some stuff can't be used, like > XInclude/XSLT/XQuery. Interesting, but not a killer to me. I do say this > with sadness as an XInclude editor, BTW. So even though there are various proposal on the table that would give back compatibility with those tools you don't think that they are worth pursuing? Anyhow, those technologies are the canary in the mine-shaft. There is a very subtle point I've been trying to get through with no success. Let's take a paragraph from an article where Joel slams me without really reading the article: "The real problem with SOAP is that it's a completely inadequate remoting system. It doesn't have events (which makes it useless for large classes of applications). It doesn't support references (ditto)." * http://www.joelonsoftware.com/ Do you think that maybe Joel is on to something here? Nobody has ever deployed a programming language, remote procedure system, database or programming runtime without *SOME SUPPORT FOR REFERENCES TO STATE FRAGMENTS*. On the Web, URIs are the reference mechanism and HTTP has all sorts of mechanisms for managing them. CORBA has object references, COM has some similar features, etc. Because SOAP lacks this, it must be done at the application level. This means that every application invents its own addressing syntax (UUIDs in UDDI, a 10-tuple in the Google doSearch API). This will be a killer barrier to interoperability and service composition. Imagine trying to compose a Java program with no references to objects. You can only call functions, get back values, reorganize those values and pass them as parameters to another function. It would never scale. It also means that when you get into complicated web services, like Hailstorm (may she rest in peace), you get really baroque addressing models like red/blue elements. In the long run these will belie the promise that web services are "easy to use" because you will have to learn who a whole new data manipulation model for each and every family of services. I don't think that anybody is consciously thinking of this as an opportunity for lock-in, but it is. I'm not trying to kill web services, I am trying to save them. > ... You've said that GET/PUT/DELETE > can be used. That's fine, but not as compelling as saying it's broken. I think that every working group's responsibility is to create technologies that to whatever extent is possible enhance all of the other W3C technologies and to whatever extent possible do not compete with them. That's why the pointer technologies from XPointer and XSLT were merged. That's why it would be inappropriate for the W3C to take on a RELAX standarization project without deprecating XML Schema (or at least clearly differentiating their market segments). Now I will be happy with SOAP when people can use SOAP, URIs and HTTP as three orthogonal technologies and get the *full* benefit of all three. If SOAP had come to the W3C in another fashion I think that this request would be fundamentally uncontroversial. We would have started out saying: "Is this new protocol a replacement for HTTP or a complement to it. If a replacement, how do we ensure that all of the virtues of HTTP are maintained. If it is to be a complement...how?" Of all the SOAP services I've seen, every one gave up *substantial* parts of the benefits of HTTP and URIs in order to use SOAP. That's not an appropriate deployment record for a web protocol. >... > And as with all RESTafarians, ;) > ... you miss the point that sometimes (gasp) > people want to use SOAP on things other than HTTP. What some people want to > do is have SOAP be a unified protocol on top of HTTP, SMTP, JMS, MQSeries, > MyFavoriteMessagingProtocol, We're talking about an HTTP binding. While the message is on HTTP it should be able to take advantage of all of the capabilities of HTTP. If SOAP were a superset of HTTP's capabilities then it MIGHT make sense to treat HTTP as "just another transport." But as I've shown and as I've tried to express above, HTTP solves one of the most important problems in a way that SOAP does not and likely will not as long as it is "transport neutral." > ... etc. TimBL himself has said that the web is > more protocols than HTTP. If we define a "web protocol" as one with capabilities for manipulating web resources through URIs then we will probably find that once we do it for HTTP it will be a lot easier to handle the rest of them also. As Noah says, maybe we can do them all at once. > ... So picking just HTTP POST makes software's job a > LOT easier. We might have an interesting discussion on why a whole bunch of > other protocols is a bad idea, but that is a different issue. Is it? If its a bad idea then forcing an HTTP-incompatibility in exchange for a feature that won't work is a bad tradeoff. Paul Prescod
Received on Thursday, 25 April 2002 19:55:26 UTC