Thursday, October 24, 2002, 1:35:03 PM, you wrote: >> It's a physical impossibility to pass xml data as >> efficiently as passing data over a COM interface. >> I accept that SOAP is a viable replacement for DCOM, >> but not COM itself.
DW> If you're defining efficiency as speed, you're absolutely correct. However, DW> the general acceptance of XML should indicate that people are often more DW> concerned with things other than speed, such as the use of (relatively DW> human-readable) text formats instead of requiring binary compatibility. An example of being too inefficient would be sending binary data over XML. Encoding a file into base64 when it used to be possible to send binary is a huge performance hit and would be unacceptable. Of course there are better ways, I'm just using this as an example. >> Especially when with all the "industries investment in >> Java" that is supposed to be a big reason we love Java >> now, nobody in Javaland has come up with as efficient >> an interface as MSXML. Just the thought of using a web >> service to parse/and receive/send XML is laughable to me. DW> What part is laughable? The part about using HTTP as a transport mechanism? DW> There's nothing preventing the use of other transport mechanisms for SOAP DW> requests. Or the part about XML parsing? People seem to be doing that just DW> fine without MSXML, in general. And, of course, using SOAP in .NET programs DW> uses the MS parser, I'm sure, so again, I'm missing something here. So you are suggesting creating a socket and sending a block of XML, using SOAP to a process listening on the same machine, that does the actual work is a decent solution? Networking socket overhead alone would make this not a viable solution for a multiuser application. The joke being the irony of the double work of parsing an xml packet, that is instructing a program how do parse an xml packet, then actually parsing the xml packet, and passing it back as...what? My sense of humor may be odd though :) In reference to the msxml comparison, msxml needs one line to actually open a connection and get the xml from within CF. Using Java it takes like 20 lines. Actually parsing the XML in java is unnecessary with CF (unlike http, which is required because of cfhttp's deficiencies), but parsing XML with Java is so incredibly complex as to be not worth it, at least not for the price range of our clients. I'm just pointing out that there are problems that have been solved with COM that have no good counterpart in Java from my point of view, and can't be replaced with web services. Hence web services != replacement for COM. -- jon mailto:jonhall@;ozline.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
