Thursday, March 17, 2005

Xml use in the browser

C|Net has an article on what people have started calling AJAX. 'A'synchronous JavaScript and Xml. I have seen people using MSXML to build these kinds of web-apps for years, but only recently have people really pulled it all together enough, such as GMail or Outlook Web-Access (OWA). In fact, MSXML's much copied XMLHTTP (a.k.a. IXMLHttpRequest) (Copied by Apple and Mozilla/Firefox) was actually created basically to support the first implementation of OWA.

I've been thinking about what our customers want in future versions of MSXML. What kind of new functionality would enable easier/faster developement of new AJAX style web applications? XForms has some interesting ideas... I've been thinking about what we might add to MSXML to make it easier to develop rich DHtml applications. XForms is an interesting source of ideas, but I worry that it removes too much control. I don't think you could build GMail on XForms, for example.

The most obvious idea, would be to add some rich data-binding. Msxml already has some _very_ limited XML data-binding support. I have not looked much into how OWA or GMail work, but I bet that a significant part of the client-side jscript is code to regenerate the UI from the XML data behind the current page. Anyone who has used ASP/PHP/etc is used to the idea of some sort of loop to generate HTML from some data. What if the browser knew how to do that for you? And knew how to push back changes from editable controls? You can do that today with ADO.

Any other ideas? For those of you playing with 'AJAX' style design. What are the pain points? (Beside browser compatibility... )

7 Comments:

Anonymous Anonymous said...

Pain point: The back button

5:19 AM  
Anonymous Anonymous said...

Why "besides browser compatibility.." :-) It's the singlemost important part. An open standard would be the right thing.

8:44 AM  
Blogger derek said...

I should have made my query a bit more clear. I work with the MSXML team. We implement DOMDocument and XMLHTTPRequest. We have no real ability to influence the DHTML implementation. What we can do is simplify your ability to use DOMDocument and XMLHTTPRequest in AJAX-like scenarios.

11:00 AM  
Blogger derek said...

I said "besides browser compatibilty" because I have no control over what Mozilla/FireFox/Safari/Opera decide to include in their products. There is a lot of room for experimentation, and there is little point in trying to create a 'standard' for something that you can't define yet.

I'm looking for ideas to play with and evaluate. Once some of those ideas are hashed out, then it might be interesting to talk to other browser implementors and see what they think. In the mean time, they are welcome to innovate on their own.

11:07 AM  
Anonymous Anonymous said...

I would be very interested to see support for 'progressive' loading (readyState==3, which seem to be broken in MSXML3, sorry I did not look at latest verions), most importantly for text files ->responseText.

I feel that main usage of HTTPRequest in a browser in the next few years will NOT be XML, but things like JSON and direct injection of HTML markup.

1:46 PM  
Anonymous Anonymous said...

Agree that XML should not be assumed (Gmail, in fact, passes ascii that can easily be put into a JavaScript array).

Make it possible to make calls cross-domain without changing a security setting.

12:21 PM  
Anonymous Anonymous said...

How about allowing multiple threads to load xml documents simultaneously? I've done some experiments and as it stands when the second thread opens a connection while the first is open the browser hangs until only one remains open. Try it yourself.

10:58 PM  

Post a Comment

<< Home