Why XmlHTTP?

Have we looked at standard DHTML alternatives to XmlHTTP? I've never used it in my AJAX apps because of browser compatibility and security dialogs cross-domain. I understand using it to connect to non-Atlas web services, but an Atlas client to Atlas web service could asychronously request data post-page load by requesting script - e.g. I could call the web service like "myservice.asmx/js?param1=foo¶m2=bar".

You are right that XmlHTTP can have browser compatibility issues, which is why a client framework like Atlas is useful. When you use Atlas, you never directly use XmlHTTP. Instead, you use Atlas abstractions built on top of it that have the necessary logic to make it work in most browsers.
I'm not sure I understand the alternative that you're suggesting. Another method that is sometimes used it to make the request into a (hidden) iframe, and get the data from there. Is that what you are referring to? Note that doing this will hit the same cross-domain limitations as using XmlHTTP (this is by design for security reasons).
David

Thanks, I understand the user doesn't use XmlHTTP directly. But the underlying layers use it exclusively (at least from my cursory examination of AtlasCore.js), limiting the browser support.
Yes, that is the technique I am referring to. It does not have cross-domain limititations (there's no reason I can't include a script from another domain - by placing the reference in my page, I am allowing that script to run in my domain). If you're interested I can point you to a live demo application on one domain requesting data from another domain (asynchronously, post-page load, no-xmlhttp).
Jim

Hi Jim,
If a page has an iframe, it can navigate that iframe to any URL. However, it cannot access the data inside that frame unless it lives in the same domain, due to cross frame scripting restrictions:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/xframe_scripting_security.asp
But maybe your are talking about something different?
thanks,
David
Does XmlHTTP restrict us to REST-style interactions with all the pre-knowlege that requires or can we use XmlHTTP for compositional discoverable SOAP? If so, I can easily imagine AJAX style pages that will need to pull data from many many sites. Imagine, for example, an enterprise window to embedded control systems accessible by SOAP such as available from
BACnet under BACnet-XML
LON using iLON 100
Tridium using the new Niagra framework
In each of these cases you are discussing a single interface pointing to multiple exposed data sources. Lets move the bar higher, then, to also pull vector XML (say SVG) from some sort of drawing room
If I have all these sources in my trusted sites, why shouldn't I be able to cross-script across them?
Hello.
I'm a much interesting in your live demo. If it possible can you send it to me at mrorbit [at] pochta.ru.
Thank you in advance.
Another method I have used is loading a script with an IE:DOWNLOAD-control and call it.
http://searchpalette.com/g/g.html
This method will work with different site, I think. Also, I believe it works on a few browsers. To incorporate this int the ASP-world might not be worth it though.
If there is any interest, I could give it a try.
Gorm Braarvig