[whatwg] about rich internat applications

[Frank Krul]

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