"MikkelFJ" <mikkelfj-anti-spam / bigfoot.com> wrote in message news:<3e5bdb78$0$137$edfadb0f / dtext01.news.tele.dk>... .... > Hmm - I could think of plenty of things to bash Microsoft with, but I'm not > surely is fair in this case. I'm no XSLT expert so I can't judge the current > state. However, I know Microsoft were very actively supporting XSLT in the The XSLT support in 6.0.2600.0000C0 is fairly conformant, just very, very, very slow. Mozilla on the same hardware is an order of magnitude faster. > Point is - reality bites, especially early adopters. I believe Microsoft in > this case did an honest attempt to cooperate with the industry as a whole > and it is not fair to slam them based on some random version now everyone > has moved on. Moved on from what? I didn't say we were using an old version of Internet Explorer. Glaxo-Smith-Klein, one of the largest pharmaceutical companies in the world, is still based entirely on Windows NT, and won't upgrade to a different version of Windows for another two years, at least. I expect that this is fairly common in business communities. I fail to see why a reasonably recent version IE should neccessarily have worse XML and XSL support than, say, Mozilla. > Without blaiming anyone in particular, there are so many differences in the > browsers, that it is fair to choose a single browser based on the intended > audience. Web applications are crappy enough as is, but supporting different > browser versions is a nightmare. Ideally, you'd be able to write your application based on the /standards/ you're using, not how any given third-party piece of software interprets them. I distribute REXML, and I try darned hard to make sure that it conforms to spec. And, I do this for free. My criticism of Microsoft was that, with all of their resources *and* all of their revenue, they can't seem to keep their software even as conformant as, well, anything else. I'm not even talking about XML and XSL anymore; IE is fundamentally an HTML renderer, and it doesn't do *that* very well. Opera (on NT), Mozilla (on NT), and Konqueror (on Linux) are all much more conformant to the CSS specs than IE on NT is. > Another point is that web applications are increasingly being used as > desktop application replacements. This puts so much stress on the client This is very true, and very unfortunate, and is certainly not MS' fault :-) > What we need is a completely new replacement of the X-windows standard for > properly building distributed applications over the internet. Meanwhile XUL would help. XForms is actually pretty nice (a nightmare to implement, but nice for form builders). I love web services, but I have a real problem with the whole servlet paradigm. People are, essentially, tacking on stateful extensions to a stateless protocol, and I find it really distasteful. On top of that, HTML is /not/ a good choice for a UI interface, and until we get universal broadband, using HTTP as the communication layer between a complex application client and the application logic on a server is a terrible idea. This is way off topic though. > I believe the primary reasons for web applacations are 1) deployment, 2) > efficient client/server performance. For some to me unknown reason, many > developers can't figure out how to write networked applications without > bogging down in network traffic, unless working writh browsers where they > are forced to reduce the number of client / server operations. Deployment is > easily solved with a click to download thin client for dedicated software - > already happens inside browsers camouflaged as plugins. 2) People should > have learned trick by now. You're right about this. You deploy web applications because everybody has a web client, so there's nothing to install. You also have tight control over the application logic, which is on the server, which is nice for maintenance, debugging, and security. If you're really careful about the information you're sending to the client, you can reduce network traffic. On the other hand, there will always be some applications that are simply better as thick client applications. Email is my favorite example. Nobody in their right mind who uses email a lot would use a webmail gateway as their primary email client, if they have an alternative. Having access to a webmail gateway is *nice*, mind you, but even over broadband, is tediously slow compared to a thick client. The fact that I have to access usenet through a web interface is the the only thing tempting me to sign up for a usenet account, so that I can use a real client. But... for the moment... imagine how nice it would be if you could use Ruby as an HTML scripting language. Mmmmmm.