- From: Frank Krul <Frank.Krul@morganstanley.com>
- Date: Wed, 09 Jun 2004 10:28:10 -0300
Brad Neuberg wrote: > I am a JSP programmer so I know this is possible in JSP (you can > intercept the HTTP response in a standard way and change things), but > I'm not sure if it is possible in other popular environments in a > standard way (PHP, Perl, ASP/ASP.Net, etc.). Also, remember that > there would be an adoption curve on the server side as well; would web > hosting providers install these convertors? If things are done on the > client side then the server-side doesn't need to change. > The real question definitely concerns the possibility of adoption; what would be easier for Microsoft, the Open Source Apache groups and Cold Fusion stakeholders to implement? Microsoft could add a .net-type of DLL or plug-in. Alliare could extend the CFML language, and Apache is easy enough to add a lib to to extend it's core services to emulate the Filters introduced in the Servlet 2.3 API (as Brad suggests) without having a JSP container installed. And there is value there since the current filter spec allows us to not only apply XSLT, byte tokenizing and trigger resource access events, but also modify binary streams received from the servers. Powerful stuff. But would these Web daemon and app server companies and platforms actually support it? One is aloof enough to let it's browser stagnate (Microsoft) and isn't very receptive to any competing technology, one values its' proprietary language (Allaire), and I see the only crowd attempting it would be Apache, and they already have the servlet spec in the Tomcat products. Heck, I've even seen people using ANT as a real-time XML serialization tool that can filter content output as well (Tridion does this in a CMS product). The alternative for them is to let the browser adoption force change when the client side has this built-in. If the developers on this group do get these technologies into the browser, and they become valuable (and that doesn't mean ubiquitous in usage among the Web developers per se, just exciting enough to generate buzz), then support among these Web and App companies would be looked into. Then we get into trickle up theory, companies like Macromedia add tag support in Dreamweaver, and then the big browsers are actually forced to commit and play in the new sandbox. > To summarize, these three metrics are Reliability, Ease of Programmer > Use, and Performance. The reason I brought these up in a discussion > of whether to put the emulation layer on the client or server sides is > because if we can't achieve these three important metrics on the > client side then we may have to do it on the server-side. > There are (arguably) a lot of technologies that are easy to use and perform well,that have never made it....what ever happened to Netscape's LiveWire? The most important metric is demographic majority. From a business perspective, none of our fortune 500 bosses are going to let us touch a technology with little market penetration. It's a sad fact of life that most companies are still parsing for browser type as N4.7+ and IE5.0+ only. Thankfully, Mozilla and Opera are gaining ground...but will I be able to persuade my stakeholders that this is a technology we should put a resource to? If it's in the best browsers, then it will have a better chance than having an open-source plug-in server architecture making the rounds. Frank Krul
Received on Wednesday, 9 June 2004 06:28:10 UTC